Azamat

Доброго дня всем. С наступающим НГ и все такое. Столкнулись с какими-то граблями на доступе к публичным сервисам гугла - само показательно - ДНС 8.8.8.8 Может быть кто-то проходил подобное и знает как решать? Суть: с части наших IP адресов недоступен резолв через 8.8.8.8, причем очень избирательно. например в некой /24 есть адрес .1 и адрес .4 и адрес .16 с .1 и .16 все ОК, резолв и другие сервисы работают без вопросов. с .4 резолва нет, хотя пинги на 8.8.8.8 ходят. Что интересно, отличается трассировка маршрута до 8.8.8.8 с каждого из адресов (.1 и .4), видать какой-то балансер на гугле ?

они написали: Hello, Thank you for reporting this issue, you can use this URL instead: http://redirector.googlevideo.com/report_mapping

Там сертификат с видимостью *.google.com, а exp дата еще далеко.

Из гугла написали про резолв: Having youtube resolve to Google IP addresses is always correct. Sometimes we attempt to do some optimization by having some Google properties resolve to GGC nodes. Я помню, что как то резолв шел на локальные адреса кэша, видимо как раз были работы со стороны Гугла.

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

Вот что имеем на dig dig @8.8.8.8 google.com ;; ANSWER SECTION: google.com. 192 IN A 209.85.233.138 google.com. 192 IN A 209.85.233.100 google.com. 192 IN A 209.85.233.101 google.com. 192 IN A 209.85.233.139 google.com. 192 IN A 209.85.233.102 google.com. 192 IN A 209.85.233.113 ;; Query time: 67 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) Должно быть как то иначе ? Кроме того, вижу что наш ДНС отдает клиенту на запрос: 16:57:17.723022 IP 192.168.150.1.53 > 192.168.141.11.64150: 55094| 17/10/0 CNAME youtube-ui.l.google.com., A 64.233.165.91, A 64.233.165.93, A 64.233.165.136, A 74.125.205.91, A 108.177.14.91, A 108.177.14.190, A 173.194.222.93, A 209.85.233.93, A 64.233.162.91, A 64.233.162.93, A 64.233.162.190, A 64.233.163.91, A 64.233.163.136, A 64.233.164.93, A 64.233.164.136, A 64.233.164.190 (499) не должны ли здесь быть адреса локального кэша ?

Всем доброго дня. Плз подскажите, если кто знает. www.youtube.com, www.google.com должны резовиться в адреса локального кэша ? А то сейчас резолв идет на их честные адреса ping www.google.com PING www.google.com (173.194.32.208): 56 data bytes 64 bytes from 173.194.32.208: icmp_seq=0 ttl=57 time=51.396 ms Есть обращения от клиентов, мол вдруг перестал работать гугл плей, мобильная версия ютуба и др. сервисы от Гугла. Причем, если ставить в качестве ДНС 8.8.8.8 - начинает работать норм. Что за глюк приключился ?

Вышестоящий интерфейс - это тоже наше железо, SVI на L3 коммутаторе Cisco. Вполне подзагружен, заняты все 48 портов на 10Гб/с и пара на 40. В башню как-то не пришла мысль, что он чего-то не могет. Судя по всему, оказца кое с чем и не может адекватно справиться. Сейчас отгоняю тест на 2К пакетов, потом на ночь поставлю 10к. Надеюсь, что данный понт получилось победить с всеобщей помощью. P.S. Тест на 2К пакетов - чисто. 64 bytes from 217.69.139.70: icmp_seq=1999 ttl=55 time=57.209 ms --- www.mail.ru ping statistics --- 2000 packets transmitted, 2000 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 56.634/57.201/58.556/0.216 ms Будем считать, что победа за человеком ( по имени All :) )

В отчаянии прибил на НАТ сервере статиком арп запись вышестоящего интерфейса - и уже два цикла по 500 пакетов без потерь. Сейчас пошел цикл в 1000 пакетов. Надеюсь, будет чисто. Как стандартное поведение АРП системы могло сказываться на потерях ? Неужели на так долго терялся мак вышестоящего интерфейса в момент expiry, что целый пакет успевал дропнуться ? PS: Чисто прошел цикл в 1000 пакетов, что не было ни разу за последние неск. дней. 64 bytes from 217.69.139.70: icmp_seq=998 ttl=55 time=57.011 ms 64 bytes from 217.69.139.70: icmp_seq=999 ttl=55 time=57.016 ms --- www.MAIL.ru ping statistics --- 1000 packets transmitted, 1000 packets received, 0.0% packet loss

Обратил внимание сейчас, что возможно в момент потери сильно снизилась нагрузка на процессор с типичных за время очередного цикла пинга 18-20 до 12-10 проц, потом произошло восстановление : 12:53:11 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 12:53:12 PM all 0.00 0.00 0.00 0.00 0.00 18.84 0.00 0.00 81.16 12:53:12 PM 0 0.00 0.00 0.00 0.00 0.00 19.19 0.00 0.00 80.81 12:53:12 PM 1 0.00 0.00 0.00 0.00 0.00 19.19 0.00 0.00 80.81 12:53:12 PM 2 0.00 0.00 0.00 0.00 0.00 18.00 0.00 0.00 82.00 12:53:12 PM 3 0.00 0.00 0.00 0.00 0.00 18.81 0.00 0.00 81.19 12:53:12 PM 4 0.00 0.00 0.00 0.00 0.00 20.19 0.00 0.00 79.81 12:53:12 PM 5 0.00 0.00 0.00 0.00 0.00 17.65 0.00 0.00 82.35 12:53:12 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 12:53:13 PM all 0.17 0.00 0.00 0.00 0.00 12.75 0.00 0.00 87.09 12:53:13 PM 0 0.00 0.00 0.00 0.00 0.00 11.22 0.00 0.00 88.78 12:53:13 PM 1 0.00 0.00 0.00 0.00 0.00 12.87 0.00 0.00 87.13 12:53:13 PM 2 0.00 0.00 0.00 0.00 0.00 12.12 0.00 0.00 87.88 12:53:13 PM 3 0.00 0.00 0.00 0.00 0.00 11.88 0.00 0.00 88.12 12:53:13 PM 4 0.00 0.00 0.00 0.00 0.00 14.56 0.00 0.00 85.44 12:53:13 PM 5 0.00 0.00 0.00 0.00 0.00 13.73 0.00 0.00 86.27 12:53:13 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 12:53:14 PM all 0.00 0.00 0.00 0.33 0.00 10.95 0.00 0.00 88.73 12:53:14 PM 0 0.00 0.00 0.00 2.00 0.00 10.00 0.00 0.00 88.00 12:53:14 PM 1 0.00 0.00 0.00 0.00 0.00 9.90 0.00 0.00 90.10 12:53:14 PM 2 0.00 0.00 0.00 0.00 0.00 10.00 0.00 0.00 90.00 12:53:14 PM 3 0.00 0.00 0.00 0.00 0.00 10.89 0.00 0.00 89.11 12:53:14 PM 4 0.00 0.00 0.00 0.00 0.00 12.50 0.00 0.00 87.50 12:53:14 PM 5 0.00 0.00 0.00 0.00 0.00 10.78 0.00 0.00 89.22 12:53:14 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 12:53:15 PM all 0.00 0.00 0.00 0.00 0.00 20.33 0.00 0.00 79.67 12:53:15 PM 0 0.00 0.00 0.00 0.00 0.00 20.00 0.00 0.00 80.00 12:53:15 PM 1 0.00 0.00 0.00 0.00 0.00 21.57 0.00 0.00 78.43 12:53:15 PM 2 0.00 0.00 0.00 0.00 0.00 17.35 0.00 0.00 82.65 12:53:15 PM 3 0.00 0.00 0.00 0.00 0.00 21.70 0.00 0.00 78.30 12:53:15 PM 4 0.00 0.00 0.00 0.00 0.00 20.19 0.00 0.00 79.81 12:53:15 PM 5 0.00 0.00 0.00 0.00 0.00 20.75 0.00 0.00 79.25 Сейчас сделаю перепроверку с записью в файл

Сейчас так net.core.dev_weight = 64 net.core.netdev_budget = 300 net.core.netdev_max_backlog = 1000 net.core.netdev_tstamp_prequeue = 1 net.netfilter.nf_conntrack_buckets = 2097152 Потеря пакета на исходящем интерфейсе "в мир" выглядит так: (на входящем из серой сети все 500 пакетов на трансляцию приходят без потерь) 11:14:31.393667 IP 212.Х > 217.69.139.70: ICMP echo request, id 33361, seq 163, length 64 11:14:33.395631 IP 212.Х > 217.69.139.70: ICMP echo request, id 33361, seq 165, length 64 11:15:31.453552 IP 212.Х > 217.69.139.70: ICMP echo request, id 33361, seq 223, length 64 11:15:33.455509 IP 212.Х > 217.69.139.70: ICMP echo request, id 33361, seq 225, length 64 Через 3-4 цикла по 500 пакетов проходит вообще без потерь --- www.MAIL.ru ping statistics --- 500 packets transmitted, 500 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 53.324/53.860/58.101/0.282 ms

Нет, ядра честные. update-initramfs - пришлось делать. Осталось порешать вопрос с мелкими потерями. Так и теряет 1-2 пакета из 500. Уже и снмп опрос выключил, думал - мало ли что. Погашу пожалуй еще демон снмп на самом сервере. perf stat -a -e cache-misses,cache-references sleep 10 Performance counter stats for 'system wide': 27238043 cache-misses # 5.784 % of all cache refs [100.00%] 470945426 cache-references 10.000608309 seconds time elapsed Терпимый показатель промахов ? Загрузка проца. 11:05:53 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 11:05:54 AM all 0.00 0.00 0.00 0.00 0.00 17.65 0.00 0.00 82.35 11:05:54 AM 0 0.00 0.00 0.00 0.00 0.00 18.00 0.00 0.00 82.00 11:05:54 AM 1 0.00 0.00 0.00 0.00 0.00 17.35 0.00 0.00 82.65 11:05:54 AM 2 0.00 0.00 0.00 0.00 0.00 15.84 0.00 0.00 84.16 11:05:54 AM 3 0.00 0.00 0.00 0.00 0.00 19.05 0.00 0.00 80.95 11:05:54 AM 4 0.00 0.00 0.00 0.00 0.00 19.05 0.00 0.00 80.95 11:05:54 AM 5 0.00 0.00 0.00 0.00 0.00 17.31 0.00 0.00 82.69

a RSS=8,8 будет сильно не хорошо ? Типа по числу ядер

Уважаемые друзья, плз подскажите еще по одной теме: в НАТ сервере проц на 8 честных ядер, но загружены 6, два последних полностью простаивают. Х/з почему :( 02:12:31 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 02:12:32 AM all 0.00 0.00 0.00 0.00 0.00 30.35 0.00 0.00 69.65 02:12:32 AM 0 0.00 0.00 0.00 0.00 0.00 39.13 0.00 0.00 60.87 02:12:32 AM 1 0.00 0.00 0.00 0.00 0.00 39.36 0.00 0.00 60.64 02:12:32 AM 2 0.00 0.00 0.00 0.00 0.00 34.78 0.00 0.00 65.22 02:12:32 AM 3 0.00 0.00 0.00 0.00 0.00 43.40 0.00 0.00 56.60 02:12:32 AM 4 0.00 0.00 0.00 0.00 0.00 42.86 0.00 0.00 57.14 02:12:32 AM 5 0.00 0.00 0.00 0.00 0.00 42.06 0.00 0.00 57.94 02:12:32 AM 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 02:12:32 AM 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 68: 2650720493 0 0 0 0 0 0 29435 PCI-MSI-edge eth1-TxRx-0 69: 0 2650680679 0 0 0 0 0 0 PCI-MSI-edge eth1-TxRx-1 70: 0 0 2656291875 0 0 0 0 0 PCI-MSI-edge eth1-TxRx-2 73: 0 0 0 2652343941 29087 0 0 0 PCI-MSI-edge eth2-TxRx-0 74: 0 0 0 0 2653065247 30610 0 0 PCI-MSI-edge eth2-TxRx-1 75: 0 0 0 0 0 2658333352 0 0 PCI-MSI-edge eth2-TxRx-2 В dmesg о сетевой: [ 4.685799] ixgbe: Receive-Side Scaling (RSS) set to 3 [ 4.685854] ixgbe: Flow Director packet buffer allocation set to 3 [ 4.847829] ixgbe 0000:01:00.0: irq 68 for MSI/MSI-X [ 4.847833] ixgbe 0000:01:00.0: irq 69 for MSI/MSI-X [ 4.847836] ixgbe 0000:01:00.0: irq 70 for MSI/MSI-X [ 4.847838] ixgbe 0000:01:00.0: irq 71 for MSI/MSI-X [ 4.849246] ixgbe 0000:01:00.0: PCI Express bandwidth of 32GT/s available [ 4.849309] ixgbe 0000:01:00.0: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%) Как можно догрузить последние ядра прерываниями сетевой ? PS Обнаружилась строка в /etc/modprobe.d в файле ixgbe.conf options ixgbe allow_unsupported_sfp=1,1 RSS=2,2 FdirPballoc=2,2 Видимо каждому гнезду сетевой RSS=2 задает по паре прерываний на тх и рх ? А ядер 8 Как то можно это дело на лету изменить ? или править и ребутить ?

не помогла замена патчкорда. Менять сервер ? может что то с оперативой за 3 года в аптайме ? Сетевые DA520 ethtool -G eth1 rx 2048 ethtool -G eth2 rx 2048 ethtool -G eth1 tx 2048 ethtool -G eth2 tx 2048 ethtool -C eth2 rx-usecs 500 ethtool -C eth1 rx-usecs 500 ethtool -A eth1 rx off tx off ethtool -A eth2 rx off tx off ethtool -K eth1 ntuple off ethtool -K eth2 ntuple off ethtool -K eth1 gro off ethtool -K eth2 gro off Сейчас два раза по 500 пакетов прошло без потерь, а раз - в сервере застряло 6-7%. Мистика.

Просмотр существующей темы про Линукс НАТ натолкнул проверить: root@HOME-NAT:~# ethtool -S eth1|grep sum rx_csum_offload_errors: 37117809 root@HOME-NAT:~# ethtool -S eth1|grep sum rx_csum_offload_errors: 37120332 Там же было написано, что рост ошибок может быть связан с патчкордом. Заменю-проверю.

На всякий случай уточню - потерю дает именно НАТ сервер, на входящий интерфейс с "серой" стороны приходят все 500 пакетов, а в сторону внешки (в данном случае, майл.ру) уходят с "белого" адреса НАТ сервера на 2-4 пакета меньше. К вышестоящим претензиев не имеем.

ethtool даёт простыню, оттуда надо какой то определенный раздел ? ifconfig - часть со статистикой по интерфейсам ? вряд ли нужны сами ип адреса ?

Всем доброго дня. Плз подскажите, кто знает. Есть сервер под Линукс, функция - НАТ, трафика порядка 6-7 гиг. Обратил внимание, что на нем теряются по 2-4 пакета из 500. Со стороны "серой" сети отправляю дозированно по 500 icmp до майл.ру, вижу что на входящий интерфейс со стороны "серой" сети все 500 пакетов приходят, но с соотв. "белого" адреса в сторону майл.ру уходят на 2-4 пакета меньше. Куда они могут деться-то между двумя интерфейсами на сервере ? Как именно продиагностировать ? Есть аналогичный сервер, сделанный клонированием с целевого - на том же трафике потерь нету. Какая доп. инфа нужна, чтобы более полно раскрыть тему ?

В X.X.X.X - все те же 84 маршрута из 670К. Ничего не изменилось с вчерашнего дня. Такое ощущение, что БГПд вдруг перестал работать с таблицей маршрутов ядра (собственно, best) , которые он должен был бы отлить в нижестоящие пиры.

Ничего нет. Тем более, что все работало до вчерашнего утра :(

Фильтров нету. neighbor X.X.X.X remote-as XXX neighbor X.X.X.X description BANK neighbor X.X.X.X soft-reconfiguration inbound neighbor X.X.X.X route-map XX in

Доброго дня, коллеги. Плз подскажите, если кто сталкивался. Есть сервер, вращается Quagga. С трех сторон приходит fullview, в kernel сформирована таблица размером: netstat -rn | wc -l 672236 Почему-то сегодня после clear bgp X.X.X.X soft out в нижестоящий пир X.X.X.X перестала отдаваться вся таблица :( Туда уехали какие-то (Total number of prefixes) 84 маршрута. Причем, есть один нижестоящий пир, куда до сих пор отдается вся таблица full, но clear там не делался, вдруг если сделать - тоже перестанет отливаться фуллвью. Вопрос - что произошло с демоном ? Ночью-то передернем, но может есть какое то внятное объяснение. Причем, если взять произвольный маршрут из таблицы маршрутизации (best), например - 1.0.128.1, то видно, что Quagga отчитывается, мол отдается маршрут в нужные пиры: show ip bgp 1.0.128.1 BGP routing table entry for 1.0.128.0/24 Paths: (3 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: X.X.X.X Y.Y.Y.Y В Y.Y.Y.Y он до сих пор реально отдается - но не делался clear В X.X.X.X - все те же 84 маршрута из 670К.

Вопрос с фильтрацией транзитн. трафика вроде закрылся, за что спс. технарям ТТК.

Нет, 35104