lacost

Хз, возможно и так. А в принципе, Ростелек не уходил с М9? последние пару-тройку лет? Вообще у него там комьюнити в числе прочих - (0,8631) - запрет анонсов всем BGP.community: (11,8631) (8631,65510) (8631,8674) (8631,25152) (8631,26415) (8631,30124) (8631,42139) (8631,42385) (8631,42728) (8631,43832) (8631,44597) (8631,45018) (8631,45029) (8631,47445) (0,8631)

Коллеги, здравствуйте. Несколько лет уже не лезу в дела маршрутизации. Вроде ходит все и ладно. А тут, краем уха слышу, что один клиент испытывает сложности с каким-то гос.ресурсом. Вроде решили, пустили через другой аплинк. Потом у другого клиента примерно такая же проблема. У тут во внутренней переписке вижу что ip гос-сервисов матчат по as12389. Сразу вспоминаю, что это РТ. Думаю, странно, они же давным давно отдавали более-менее локальные для себя ресурсы на мск-ix. А тут проблема с доступом. Зачем маршруты на них пускать через третьи руки? Иду на маршрутизатор на М9, смотрю бгб и вижу, что ни одного префикса на мск-ix нет от ростелека. LG подтвердил, что хоть ростелек и есть на MSK-IX, анонсы он свои не раздает всем подряд, а только, судя по всему, каким-то служебным as-кам. Давно это с ростелеком? Он же вроде оператор всея госсресурсов? Или я пытаюсь стюардессу откопать которую года 3 как закопали?

Заменили. Волшебство в действии. Вместо 2х серверов, те же задачи тащит один сервер. Поставили в боевой тест. @vurd - спасибо за наводку.

Сделали апгрейд соединения 1 .3 - 2.4 на 10GE Вообще ничего не изменилось. Все так же. Включаем tc на Сервер 1 - начинаются потери на Сервер 2 До этого проверяли направление из интернета в локалку - после включения tc на "Сервер 1" - "Сервер 2" перестает форвардить эти ICMP. Решили изменить направление теста. Тестируем из локалки в инет. Пакет пролетает через Сервер1, приходит на Сервер2 и там пропадает. Трафика между Сервер1 и Сервер2 кроме IPv4 и ARP в tcpdump не видно. При этом, параллельно с запущенным пингованием длинными (3000) пакетами iperf работает и показывает заявленную (6 Мбит/сек) скорость. Т.е. эффект заметен только на фрагментированных пакетах. Пинг 1472 еще проходит, выше - нет. Может быть при включении tc на Сервер1 начинают как-то маркироваться пакеты, и Сервер2 принимает решение прекратить маршрутизацию? Или может быть Сервер 2 начинает собирать части в большой пакет и он не проходит?

Да, ровно 1000

Насильно отключаем Flow Control на всех интерфейсах ethtool -A eno1 autoneg off rx off tx off Начинаем наливать трафик Через некоторое время - опять потери. смотрю по всем интерфейсам статистику по отправке #ethtool -S eno1 | grep flow rx_flow_control_xon: 0 rx_flow_control_xoff: 0 tx_flow_control_xon: 0 tx_flow_control_xoff: 0 В tcpdump не вижу никакого служебного трафика, везде пустота. tcpdump -nni any ether proto 0x8808 tcpdump -nni any not ip and not arp снимаем шейпер с исходящего (Сервер 1) - потери прекращаются. ПС. Небольшое дополнение к схеме. Сейчас работаем с линком 1.3 - 2.4 в Bond'е 2х1Ge с каждой стороны.

Про Flow Control понял. проверим. А вот здесь вообще не понял:

Да, но там только исходящий из 1.3 в 2.4 и нагрузка там 5-10% от входящего. Перегруза там нет.

Коллеги, столкнулись с необъяснимыми потерями пакетов на макете. Т.е. мы пока не смогли найти этому какое-либо внятное объяснение. Данная схема у нас годами работала, но на новой паре серверов видим странную картину. Есть пара серверов, Debian на ядре 4.19.0-13-amd64. В каждом по паре сетевых карт Intel X520 (с последними драйверами) Сервера между собой соединены гиговыми портами. 10Г линки - в коммутатор. Два сервера. Задача 1-го - NAT клиентов которых не надо шейпить. Задача 2-го - NAT клиентов которых надо шейпить + непосредственно шейп. Исходящий из сети трафик всегда заходит на сервер 1 интерфейс 1.1 на нем принимается решение (по src_ip) нужно ли этот трафик шейпить , и если нужно, трафик идет через интерфейс 1.3 на сервер 2 в интерфейс 2.4. При выходе с интерфейса 1.3 трафик шейпится. На сервере 2 происходит NAT и трафик через интерфейс 2.6 уходит в инет. Вариант, где трафик не надо шейпить - работает нормально. Его не рассматриваем. Входящий из инета приходит на сервер 2 интерфейс 2.6, проходит NAT и шейпясь, через 2.5 уходит во внутреннюю сеть. NAT - iptables persistent, + часть клиентов с реальниками на картах с no_track шейпинг tc qdisc htb Далее последовательность действий которая приводит к 100% исходу. тестовый клиент - ноут с реальным ip на сетевой карте. Если не включаем шейпинг - все ходит. Включаем шейпинг на исходящий трафик (интерфейс 1.3) на уровне 6Мбит/сек и смотрим ролик с HD-видео. Начинаем пинговать реальный интерфейс тестового ноута большими пакетами -s 3000 с граничного маршрутизатора. Видео - ОК, пинги в норме. Начинаем наливать в эту связку (сервера 1 и 2) трафик от реальных пользователей на 3-5 ГБит/сек Через некоторе время, не сразу (от 30 сек до нескольких минут) начинают теряться пинги. Потери идут пачками 10-15 пакетов потерялись, потом опять проходят. Убрали tc c интерфейса 1.3 - потери пропали. Теперь про потери. tcpdump на сервере 2 интерфейсах 2.5 и 2.6 смотрим icmp от хоста источника пингов и хост назначения пингов. Штатно вижу реквест пакет на 2.6 и реквест пакет на 2.5 и реплай пакет на 2.6 Как начинаются потери - я все еще вижу реквест пакеты на интерфейс 2.6 но дальше - ничего. на 2.5 я их уже не вижу. Добавляли -j LOG во все (raw, mangle, filter, nat ) цепочки iptables. Как только начинаются потери пингов - так и в логах прекращаются новые записи. Пакет просто растворяется. Я даже не представляю куда он пропадает. У меня есть единственное объяснение данному эффекту: между сервером 1 и 2 есть какая-то связь, которая появилась в новых дистрибутивах/ядрах, которая при повышенной нагрузке как-то уведомляет соседей о перегрузке линка? Для меня вообще не понятна связь между установкой tc qdisc дисциплины на одном сервере, что влечет за собой сбой в маршрутизации пакетов на другом сервере. Или я чего-то упускаю? Что это может быть?

Мы не подписывали новый договор. Договорились внести доп.линии в старый и перевести с км на штуки.

Ну вы даете. Спросил конкретный вопрос по конкретной теме. Думал, хоть один стоящий ответ будет. Не писал раньше в "бумаги"... и наверное хорошо, что не писал. Меня интересовала не вода в виде воды, а конкретная практика с конкретной компанией-монополистом и НДД к инфраструктуре. В итоге, пока отбился от обеспечительного платежа и демонтажа.

Здравствуйте. Законно ли включение в первоначальный платеж помимо оплаты за квартал вперед стоимости подвеса, так же обеспечительный платеж в размере того же квартала, а так же демонтаж? На круг выходит 3-4 цены квартального подвеса. Против оплаты подвеса - не возражаем, но вот законно ли требование обеспечительного платежа и демонтажа? Ссылка к здравому смыслу во время обсуждения условий договора не возымела результата. Пришел ответ, что это стандартный договор. Конечно, кто будет отказываться от лишних денег лежащих на счете? Есть ли кто из МО с договорами на подвес по ВЛ? Подскажите как у вас было? Как по законодательству? Спасибо.

Алексей, сразу спасибо за помощь. Ни в коем случае не хочу в чем бы то ни было вас обвинять. Опять же полностью понимаю ваш ответ по поводу старой прошивки. На данный момент у меня рабочим вариантом - идея поставить параллельно S300 и ночами, пытаться перекидывать интерфейсы на него и смотреть по загрузке.

В сапорт написали. Но, экспериментировать на живых людях в карантин не решились. В итоге убрали новое - вернули старое. Со старым все работает. Алексей, вы отписались в традиционном стиле: меняйте прошивку на новую - разбираться с вашим старьем 4-х летней давности нет смысла, и в принципе, я вас как технарь - понимаю. Но, с другой стороны, у нас есть несколько таких же коммутаторов, с точно такими же прошивками (080) которые точно такой-же трафик от точно таких же абонентов переваривают нормально. Вот теперь сидим и думаем: проблема с коммутатором была, и осталась не решена. Точно такая же проблема может случиться на работающих коммутаторах - а там решать ее не чем. На тех районах, где уже стоит S300 старый вариант с Длинками 3627 и 3620 уже не справлялся. Опять останавливать сеть на районе, менять там коммутатор на S300 и "ждать решения" - это точно не вариант. Все же хочу вернуться к вопросу проблемы, хоть и постфактум. Симптомы: высокая загрузка самого коммутатора (хрен бы с ним), нет arp записи шлюза у клинета. Перезагрузка клиента - помогает. Поправьте меня, если я ошибаюсь, но мне кажется что моя основная проблема (клиент не работал) была обусловлена следующим: show cpu-rx protocol all Type Rate-limit TotPkts DropPkts ALL_ARP 200 0 0 ARP  400 4665553 67768 Значит, что arp-запросов очень много для данного Rate-limit, и часть этих пакетов сбрасывается. У клиента, по истечении таймаута, начинает протухать arp-запись шлюза. Клиент делает запрос на who-has gw_ip Данный запрос, из-за перегруза по rate-limit сбрасывается на коммутаторе. Клиент после нескольких не успешных попыток прекращает работу. Если это все так, то какой rate-limit считается нормальным для 3-4К arp-записей? Без разбора, просто по EtherType и все? Для вас этого оказалось достаточно? Если я везде не прав, то дайте наводку - куда смотреть, что мониторить на коммутаторе, где наблюдается проблема по загрузке? Есть там не документированные команды по поиску/профилированию состояния коммутатора? За эти пару дней, что сражались с проблемой - документация была изучена, и там ничего подобного найдено не было.

Было: _SNR_S300G# show cpu-rx protocol all --------------------------Slot : 1---------------------- Type Rate-limit TotPkts DropPkts ALL_ARP 200 0 0 ARP 400 4665553 67768 BFD 400 0 0 BFD6 400 0 0 BGP 200 0 0 BGP4+ 200 0 0 BPDU_TUNNEL 100 0 0 CFMOAM_CCM 300 0 0 CFMOAM_OTHER 200 0 0 CLUSTER-DP 300 0 0 CLUSTER-DR 300 0 0 DAI-ARP 200 0 0 DHCP 200 0 0 DHCP-SNOOPING 200 0 0 DHCP_SUPPRESS 200 0 0 DHCPv6 200 0 0 DHCPv6-SNOOPING 200 0 0 DMAC-CPU 300 0 0 DNS 100 3637 0 DOT1x 100 0 0 EAPOU 100 0 0 ECP 400 0 0 ERPS 60 0 0 ERSPAN 50 0 0 FTP 500 0 0 FTP6 500 0 0 GVRP 20 0 0 HSRP 100 0 0 HTTP 200 0 0 HTTP6 200 0 0 HTTPS/SSL 200 0 0 HTTPS6/SSL6 200 0 0 ICMP-REDIRECT 50 0 0 IGMP 200 156722 0 IPV6-HOPLIMIT 100 0 0 IPv6-NTP 50 0 0 ISIS 100 0 0 ISIS_TRILL 1000 0 0 L3-STATION-MOVE 100 0 0 LACP 40 0 0 LDP 200 0 0 LLDP 20 0 0 LOCAL-IPUC 500 97558 0 LOCAL-IPV6UC 200 0 0 LOOPBACK 20 0 0 MLD 200 0 0 MRPP 20 0 0 MULTICAST 20 8951 442 MULTICAST6 20 0 0 NDP-SNOOPING 400 0 0 NS-NA 200 6254 0 NTP 50 0 0 OFP-CONTROL 400 0 0 OFP-NOTMATCH 200 0 0 OSPF 100 264213 432 OSPF6 100 0 0 OTHER-IPUC 200 328901 12721 OTHER-IPV6UC 200 0 0 PIM 200 69965 0 PIM6 200 0 0 PPPoE 200 0 0 PROTECT-ARP 50 0 0 PROTECT-ICMP 60 0 0 RA-SNOOPING 100 0 0 RADIUS 100 0 0 RADIUS6 100 0 0 RIP 100 0 0 RIP6 100 0 0 RS-RA 100 76849 0 SFLOW 50 0 0 SNMP 500 67046 0 SNMP6 500 0 0 SRCMAC-LEARN-LIMIT 10 0 0 SSH 100 0 0 SSH6 100 0 0 STP 80 0 0 TACACS 100 0 0 TACACS6 100 0 0 TELNET 100 4249 0 TELNET6 100 0 0 TFTP 500 0 0 TFTP6 500 0 0 TRILL 100 0 0 TUNNEL-MTU-ERR 10 0 0 TYPE-TTL0 100 12947 11962 ULDP 20 0 0 ULPP 300 0 0 UNKNOW-SMAC 100 0 0 VRRP 100 0 0 VRRP6 100 0 0 mac-in-mac 200 0 0 TOTAL-LIMIT 1200 после ввода local-arp enable и cpu-rx prorocol arp 600 show cpu utilization Last 5 second CPU USAGE: 60% Last 30 second CPU USAGE: 61% Last 5 minute CPU USAGE: 65% From running CPU USAGE: 61% и #show cpu-rx protocol arp --------------------------Slot : 1---------------------- Type Rate-limit TotPkts DropPkts ARP 600 4709584 67768 TOTAL-LIMIT 1200