[smart85]

Коллеги, добрый день!

С ~18:00 часов пятницы 26 сентября 2014 года начались проблемы с Интернетом. Мониторинг начал докладывать о проблемах с аплинками, падали то по одному. то сразу два (физика жива, просто IP адрес BGP-neighbor`а не отвечает на icmp echo request). Жалобы пользователей - от полной недоступности до просто диких тормозов при доступе к глобальным ресурсам.

 

В качестве пограничного маршрутизатора мы используем Juniper J6350:

user@border-gw0> show version

Hostname: border-gw0

Model: j6350

JUNOS Software Release [10.2R3.10]

 

Держит две BGPv4 full view таблицы от двух аплинков:

user@border-gw0> show configuration protocols bgp

group UPSTREAMS {

type external;

traceoptions {

file UPSTREAMS_bgp4.log size 1m files 50;

}

description EXT-UPSTREAMS;

hold-time 30;

advertise-inactive;

no-advertise-peer-as;

out-delay 15;

log-updown;

local-as XXXXX0;

neighbor XX.XXX.XXX.49 {

description "ISP#1 p2p link";

preference 200;

local-preference 200;

local-address XX.XXX.XXX.50;

import [ RFC1918-reject BOGUS-ASes default-route-reject ];

export adv-aggr;

remove-private;

peer-as XXXX;

}

neighbor XXX.XX.XXX.69 {

description "ISP#2 p2p link";

multihop {

ttl 5;

}

preference 100;

local-preference 100;

local-address XX.XXX.XXX.110;

import [ RFC1918-reject BOGUS-ASes default-route-reject ];

export adv-aggr;

remove-private;

peer-as XXXX;

}

}

 

 

Защита control-plane организована, дропается все кроме нужного - bgp от пограничника до соседей, icmp, snmp, ntp, dns.

 

Итак, конкретно симптомы (в один момент времени):

- теряются пакеты в мир - 100%

- теряются пакеты до lo0 пограничного маршрутизатора - 100%

- теряются пакеты до inside интерфейса маршрутизатора - до 30-40% потерь

 

При этом:

user@border-gw0> show bgp summary

Groups: 2 Peers: 2 Down peers: 0

Table Tot Paths Act Paths Suppressed History Damp State Pending

inet.0 1020838 514515 0 0 0 0

Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...

XX.XXX.XXX.49 XXXX 95101 694 0 0 1:44:00 4378/510644/510644/0 0/0/0/0

XXX.XX.XXX.69 XXXX 85592 213 0 0 31:28 510137/510194/510193/0 0/0/0/

И инет с самого пограничника доступен без потерь:

user@border-gw0> ping 8.8.8.8 count 10

PING 8.8.8.8 (8.8.8.8): 56 data bytes

64 bytes from 8.8.8.8: icmp_seq=0 ttl=51 time=17.866 ms

64 bytes from 8.8.8.8: icmp_seq=1 ttl=51 time=19.970 ms

64 bytes from 8.8.8.8: icmp_seq=2 ttl=51 time=18.961 ms

64 bytes from 8.8.8.8: icmp_seq=3 ttl=51 time=18.674 ms

64 bytes from 8.8.8.8: icmp_seq=4 ttl=51 time=17.642 ms

64 bytes from 8.8.8.8: icmp_seq=5 ttl=51 time=19.497 ms

64 bytes from 8.8.8.8: icmp_seq=6 ttl=51 time=19.394 ms

64 bytes from 8.8.8.8: icmp_seq=7 ttl=51 time=18.723 ms

64 bytes from 8.8.8.8: icmp_seq=8 ttl=51 time=18.250 ms

64 bytes from 8.8.8.8: icmp_seq=9 ttl=51 time=18.648 ms

 

--- 8.8.8.8 ping statistics ---

10 packets transmitted, 10 packets received, 0% packet loss

round-trip min/avg/max/stddev = 17.642/18.762/19.970/0.691 ms

 

user@border-gw0> ping 194.87.0.50 count 10

PING 194.87.0.50 (194.87.0.50): 56 data bytes

64 bytes from 194.87.0.50: icmp_seq=0 ttl=57 time=4.003 ms

64 bytes from 194.87.0.50: icmp_seq=1 ttl=57 time=3.607 ms

64 bytes from 194.87.0.50: icmp_seq=2 ttl=57 time=4.068 ms

64 bytes from 194.87.0.50: icmp_seq=3 ttl=57 time=3.584 ms

64 bytes from 194.87.0.50: icmp_seq=4 ttl=57 time=4.942 ms

64 bytes from 194.87.0.50: icmp_seq=5 ttl=57 time=4.152 ms

64 bytes from 194.87.0.50: icmp_seq=6 ttl=57 time=3.596 ms

64 bytes from 194.87.0.50: icmp_seq=7 ttl=57 time=3.603 ms

64 bytes from 194.87.0.50: icmp_seq=8 ttl=57 time=3.607 ms

64 bytes from 194.87.0.50: icmp_seq=9 ttl=57 time=3.604 ms

 

--- 194.87.0.50 ping statistics ---

10 packets transmitted, 10 packets received, 0% packet loss

round-trip min/avg/max/stddev = 3.584/3.877/4.942/0.415 ms

 

 

С мира пинг до lo0 пограничника выглядит так:

--- XXX.XXX.XXX.250 ping statistics ---

4559 packets transmitted, 2271 packets received, 50.2% packet loss

round-trip min/avg/max/stddev = 30.023/84.933/1274.155/40.094 ms

По загрузке:

user@border-gw0> show chassis forwarding

FWDD status:

State Online

Microkernel CPU utilization 2 percent

Real-time threads CPU utilization 82 percent

Heap utilization 82 percent

Buffer utilization 2 percent

Uptime: 1 hour, 48 minutes, 50 seconds

 

user@border-gw0> show chassis routing-engine

Routing Engine status:

Temperature 20 degrees C / 68 degrees F

CPU temperature 49 degrees C / 120 degrees F

Total memory 2048 MB Max 1249 MB used ( 61 percent)

Control plane memory 1472 MB Max 780 MB used ( 53 percent)

Data plane memory 576 MB Max 472 MB used ( 82 percent)

CPU utilization:

User 0 percent

Real-time threads 78 percent

Kernel 0 percent

Idle 22 percent

Model RE-J6350-3400

Serial ID XXXXXXX

Start time 2014-09-28 20:16:14 UTC

Uptime 1 hour, 49 minutes, 44 seconds

Last reboot reason 0x10:misc hardware reason

Load averages: 1 minute 5 minute 15 minute

0.36 0.32 0.52

В момент лагов девайс не ответает на SNMP, SSH, но если ранее висела сессия, то она остается живой.

Иногда, через рандомное время ситуация раздупляется, все работает минут 5-10, потом опять дикие потери пакетов через пограничник.

Один или два аплинка в апе не меняет ситуацию.

Трафик - 50-80 Мбит.

 

Коллеги, помогите, в чем может быть проблема? Спасибо!

Edited September 28, 2014 by mse.rus77

[DVM-Avgoor]

Дык может ддосят? :)

Так-то бедный офисный писюк на ддосы не рассчитан.

[NikBSDOpen]

Недостаточно информации , при ДДОС этот "почетный пенсионер" флапал бы по bgp. Хотя его перегружали похоже.

Уважаемый ТС попробуйте порезать префиксы до нулей, посмотрите что будет. Отфильтруйте ntp на re, Возможно все же он, режте ntp.

[smart85]

Дык может ддосят? :)

Так-то бедный офисный писюк на ддосы не рассчитан.

На ДДОС не похоже, трафик - мизер (в пике 120Мбпс), преобладает исходящий (думаю торренты), полезную нагрузку отключал, ситуация не меняется.

[smart85]

Недостаточно информации , при ДДОС этот "почетный пенсионер" флапал бы по bgp. Хотя его перегружали похоже.

Уважаемый ТС попробуйте порезать префиксы до нулей, посмотрите что будет. Отфильтруйте ntp на re, Возможно все же он, режте ntp.

Флапов нет, проверял. Девайс ребутал, да.

На данный момент NTP-трафик дискардится на lo0:

policer MNGMNT-1M {

if-exceeding {

bandwidth-limit 1m;

burst-size-limit 625k;

}

then discard;

}

policer MNGMNT-5M {

if-exceeding {

bandwidth-limit 5m;

burst-size-limit 625k;

}

then discard;

}

policer MNGMNT-512k {

if-exceeding {

bandwidth-limit 512k;

burst-size-limit 25k;

}

then discard;

}

 

filter accept-bgp {

interface-specific;

term accept-bgp {

from {

source-prefix-list {

BGP-neighbors-v4;

}

destination-prefix-list {

BGP-locals-v4;

}

protocol tcp;

port bgp;

}

then {

count accept-bgp;

accept;

}

}

}

 

filter accept-ssh {

term accept-ssh {

from {

destination-prefix-list {

LOCALS-v4;

}

protocol tcp;

destination-port ssh;

}

then {

policer MNGMNT-5M;

count accept-ssh;

accept;

}

}

}

filter accept-snmp {

term accept-snmp {

from {

source-prefix-list {

SNMP-clients;

SNMP-community-clients;

}

destination-prefix-list {

INTERNAL-locals;

}

protocol udp;

destination-port [ snmp snmptrap ];

}

then {

count accept-snmp;

accept;

}

}

}

 

term discard-icmp-fragments {

from {

is-fragment;

protocol icmp;

}

then {

count discard-icmp-fragments;

discard;

}

}

term accept-icmp {

from {

protocol icmp;

icmp-type [ echo-reply echo-request time-exceeded unreachable source-quench router-advertisement parameter-problem ];

}

then {

policer MNGMNT-1M;

count accept-icmp;

accept;

}

}

}

 

filter accept-traceroute {

term accept-traceroute-udp {

from {

destination-prefix-list {

LOCALS-v4;

}

protocol udp;

ttl 1;

destination-port 33434-33450;

}

then {

policer MNGMNT-1M;

count accept-traceroute-udp;

accept;

}

}

term accept-traceroute-icmp {

from {

destination-prefix-list {

LOCALS-v4;

}

protocol icmp;

ttl 1;

icmp-type [ echo-request timestamp time-exceeded ];

}

then {

policer MNGMNT-1M;

count accept-traceroute-icmp;

accept;

}

}

term accept-traceroute-tcp {

from {

destination-prefix-list {

LOCALS-v4;

}

protocol tcp;

ttl 1;

}

then {

policer MNGMNT-1M;

count accept-traceoute-tcp;

accept;

}

}

}

filter accept-dns {

term accept-dns {

from {

source-prefix-list {

DNS-servers-v4;

}

destination-prefix-list {

LOCALS-v4;

}

protocol udp;

source-port 53;

}

then {

policer MNGMNT-1M;

count accept-dns;

accept;

}

}

}

 

filter discard-all {

term discard-ip-options {

from {

ip-options any;

}

then {

count discard-ip-options;

log;

discard;

}

}

term discard-TTL_1-unknown {

from {

ttl 1;

}

then {

count discard-TTL_1-unknown;

log;

discard;

}

}

term discard-tcp {

from {

protocol tcp;

}

then {

count discard-tcp;

log;

discard;

}

}

term discard-udp {

from {

protocol udp;

}

then {

count discard-udp;

log;

discard;

}

}

term discard-icmp {

from {

from {

destination-prefix-list {

LOCALS-v4;

}

protocol icmp;

}

then {

count discard-icmp;

log;

discard;

}

}

term discard-unknown {

then {

count discard-unknown;

log;

discard;

}

}

}

filter accept-common-services {

term protect-TRACEROUTE {

filter accept-traceroute;

}

term protect-ICMP {

filter accept-icmp;

}

term protect-SSH {

filter accept-ssh;

}

term protect-SNMP {

filter accept-snmp;

}

term protect-DNS {

filter accept-dns;

}

}

Пробовал принимать только дефолт от одного аплинка, результат был аналогичным.

[DVM-Avgoor]

На ДДОС не похоже, трафик - мизер (в пике 120Мбпс),

 

Мегабиты не показатель, наблюдайте PPS.

[NikBSDOpen]

Примите дефолт от обеих и разгрузите память. Посмотрите по top, что жрет память, когда начинается эта ерунда. Еще, если все-равно заребутили, то снимите крышку с "PC", выдерните память, почистите контакты резинкой, замените ее на другую.

[smart85]

На ДДОС не похоже, трафик - мизер (в пике 120Мбпс),

 

Мегабиты не показатель, наблюдайте PPS.

По PPS ситуация следующая (интерфейс смотрит на ядро сети):

mse@border-gw0> show interfaces ge-0/0/3

Physical interface: ge-0/0/3, Enabled, Physical link is Up

Interface index: 136, SNMP ifIndex: 511

Link-level type: Ethernet, MTU: 1514, Link-mode: Full-duplex, Speed: 1000mbps, BPDU Error: None, MAC-REWRITE Error: None,

Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online

Device flags : Present Running

Interface flags: SNMP-Traps Internal: 0x4000

Link flags : None

CoS queues : 8 supported, 8 maximum usable queues

Current address: 88:e0:f3:2e:3e:03, Hardware address: 88:e0:f3:2e:3e:03

Last flapped : 2014-09-28 20:17:27 UTC (17:37:46 ago)

Input rate : 51689864 bps (149668 pps)

Output rate : 10983248 bps (1539 pps)

Active alarms : None

Active defects : None

[smart85]

Примите дефолт от обеих и разгрузите память. Посмотрите по top, что жрет память, когда начинается эта ерунда. Еще, если все-равно заребутили, то снимите крышку с "PC", выдерните память, почистите контакты резинкой, замените ее на другую.

Пробовали, результата нет. На момент проблем тор показывает:

last pid: 3286; load averages: 0.26, 0.21, 0.20 up 0+17:46:10 14:01:54

58 processes: 2 running, 56 sleeping

CPU states: 37.1% user, 0.0% nice, 3.1% system, 0.5% interrupt, 59.3% idle

Mem: 215M Active, 353M Inact, 771M Wired, 147M Cache, 69M Buf, 513M Free

Swap:

 

PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND

1023 root 1 107 0 623M 609M RUN 162:54 11.23% flowd_hm

1011 root 1 4 0 403M 382M kqread 18:48 5.42% rpd

1009 root 1 96 0 14808K 11640K select 0:22 0.10% snmpd

1039 root 1 4 0 4636K 2812K kqread 3:09 0.00% mcsnoopd

1005 root 1 96 0 21156K 9008K select 0:32 0.00% chassisd

1012 root 1 96 0 10040K 4448K select 0:23 0.00% l2ald

1040 root 1 96 0 3160K 908K select 0:19 0.00% license-check

1002 root 1 96 0 1608K 1092K select 0:13 0.00% bslockd

1037 root 1 96 0 8164K 4704K select 0:13 0.00% utmd

1006 root 1 96 0 4468K 2356K select 0:10 0.00% alarmd

1010 root 1 96 0 11304K 7212K select 0:07 0.00% mib2d

1021 root 1 96 0 3788K 2292K select 0:05 0.00% irsd

1018 root 1 96 0 10868K 4856K select 0:04 0.00% kmd

1036 root 1 96 0 6320K 3500K select 0:04 0.00% rtlogd

1004 root 1 96 0 20728K 4292K select 0:04 0.00% dcd

1035 root 1 96 0 82912K 5140K select 0:03 0.00% idpd

1019 root 1 96 0 4676K 2620K select 0:03 0.00% ppmd

770 root 1 96 0 4088K 2356K select 0:02 0.00% eventd

1014 root 1 96 0 8936K 3984K select 0:02 0.00% pfed

1033 root 1 96 0 6732K 3504K select 0:02 0.00% pkid

1016 root 1 96 0 6532K 3700K select 0:02 0.00% rmopd

1022 root 1 96 0 6408K 3488K select 0:02 0.00% bfdd

1032 root 1 96 0 7532K 4504K select 0:01 0.00% nsd

1026 root 1 96 0 7680K 3480K select 0:01 0.00% lacpd

1007 root 1 96 0 5324K 2216K select 0:01 0.00% craftd

1017 root 1 96 0 9544K 4756K select 0:01 0.00% cosd

1031 root 1 96 0 6164K 3292K select 0:01 0.00% jsrpd

3266 root 1 96 0 6024K 2504K select 0:01 0.00% sshd

3274 mse 1 8 0 16148K 10944K wait 0:01 0.00% cli

3271 root 1 96 0 6024K 2504K select 0:01 0.00% sshd

[NikBSDOpen]

Такое ощущение , что всетаки происходит флап по bgp, т.к. rpd слишком много жрет. Все же похоже на мелкий ддос. Пробуйте BGP, SNMP, SSH, NTP, DNS, ICMP, TRACEROUTE, фильтровать пакеты по source и destination ip.

Обновитесь на рекомендуемый 12.1X44-D35.5 junos.

[smart85]

Такое ощущение , что всетаки происходит флап по bgp, т.к. rpd слишком много жрет. Все же похоже на мелкий ддос. Пробуйте BGP, SNMP, SSH, NTP, DNS, ICMP, TRACEROUTE, фильтровать пакеты по source и destination ip.

Обновитесь на рекомендуемый 12.1X44-D35.5 junos.

Оставлял только bgp с явным указанием src и dst адресов, остальное дискардил, не помогло.

В show bgp summary сессия висит с прошлого ребута, а те флапы, что засчитаны - они из-за того, что руками клал интерфейсы аплинков.

 

А где можно стянуть софт - 12.1X44-D35.5 junos ?

 

Спасибо!

[NikBSDOpen]

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

 

https://yadi.sk/d/DLkidtipbiPpn

[smart85]

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

 

https://yadi.sk/d/DLkidtipbiPpn

Спасибо! Попробую этот софт. Пока проблема не решилась временно на тазике подняли vyos с одним аплинком с FV, полет нормальный, потерь и проблем нет.

[NikBSDOpen]

Все же протрите резинкой контакты или замените память на джунике. И термопасту поменяйте на проце.

[smart85]

Коллеги, с прискорбием сообщаю:

- протирка памяти ластиком

- обновление ПО

- танцы с бубном в виде работы с одним аплинком и без приема FV

 

к положительному результату не привели, проблема имеет место быть. Опять вернулись на тазик с vyos.

 

В какую еще сторону можно копать? От коллеги поступило предложение изъять из роутра планки памяти, засунуть в PC и пройтись memtest`ом, думаем провернуть этот процесс, отсюда вопрос: на планках написано PC-3200 compilance - в какую PC-мать это можно запихнуть?

 

Спасибо за любые советы и идеи!

[DVM-Avgoor]

А если юзеров от него отключить?

[smart85]

А если юзеров от него отключить?

Отключал, продолжает терять пакеты до lo0, пока не положу оба аплинковых интерфейса - тогда пинги перестают теряться, но и инета соответственно нет.

[pfexec]

эээ.. а зачем вы хомячка мучаете на 10.2 жуносе ? там же statefull билд. а пакетный режим работы вообще включен ? может имеет смысл обновиться на рекомендед ? так то 10.2 - тот еще анахронизм.

возможно, уткнулись в лимит сессий или чего еще такое фаервольное. попробуйте посмотреть show security flow statistics и всё что рядом.

но если заниматься некрофилией, то последний stateless билд для j-series - 9.3R4.4, но вы его уже не скачаете, но можно кого-нибудь попросить скачать. ну или если повезет я его у себя где найду, но маловероятно.

у меня в одном месте успешно несколько лет жил J-series с двумя fv и 9.3R4.4 жуносом, спецом даунгрейдил :) но их время давно прошло.

посмотрите на M7i/M10i или на MX5/20/40/80 в качестве прицела на апгрейд. ну или какой б/у T320 с ебаев притащите, тоже вариант.

 

вобщем ваши варианты для действий:

1. проверить не кончились ли у него где фаервольные фичи

2. попробовать обновиться на рекоммендованный жунос (читайте внимательно как это делать, с 10.2 до рекоммендеда вы за раз не сможете прыгнуть. проще всего это сделать с флешкой или нетворк-инсталом с форматом и накатом конфига)

3. попробовать откатиться на стейтлес билд жуноса - 9.3R4.4, если конечно где найдете. опять же, желательно с форматом и накатом конфига из бекапа. (не уверен что сейчас это хорошая идея, т.к. было закрыто много уязвимостей и багов самого junos'а после eol 9.3 ветки)

4. в список можно было бы добавить поиск багов в prsearch'е и обращение в jtac, но видимо саппорта нет, иначе бы вы тут не писали, да junos этой ветки давно eol и вероятно разговор с саппортом начнется с "обновите junos".

5. ну и, конечно, озаботиться вопросом замены железки.

 

upd:

тут прочитал до конца тему, оказывается уже почти всё испробовано.

во-первых, вы не забывайте, что вся J-серия - это обычные "писюки" на тех же целеронах и пентиумах. никакого разграничения между контрол-плейном и дата-плейнов в привычном его смысле тут нет. да, juniper крутые rt-патчи замутил к ядру freebsd и его процессы знают своё место, но всё таки если валит трафик на "контрол-плейн", то "рейтлимит" на лупбаке не будет таким эффективным как на M/MX.

во-вторых, если есть подозрение что флапаются сессии, то изучите ошибки с которыми они падают, верните в состояние "по-умолчанию" все таймеры, что вы поменяли непонятно зачем. верните на интерфейсах mtu в дефолт. посмотрите на счетчик апдейтов, вдруг просто валит их очень много.

в-третьих, 120Mbps и 150kpps для 6350 - это копейки. 4350 успешно тащил в 5 раз больше и еще оставался запас, а она так то слабее раза в полтора. у вас явно где-то ошибка в конфигурации, подумайте какие изменения последние вносились.

в-четвертых, при флапе бгп-сессий с фуллвью потери неизбежны: rpd должен удалить старые маршруты из таблицы форвардинга и поставить туда новые, попутно успев пересчитать бест. задача очень даже громоздкая, особенно учиытвая что сейчас этих маршрутов более 500к. пробуйте включить дампинк на пирах, покрошить все префиксы длиннее /24.

можно еще попробовать вообще оставить дефолты на каждом из линков и выключить сохранение апдейтов.

в-пятых, пришло время прочитать про траблшуттинг. :)

Edited October 3, 2014 by pfexec

[smart85]

Коллеги, доброго времени суток!

В общем, танцы с бубном не помогли, проблема не решена. В итоге к нам едет ревизор, а точнее Juniper M7i с неизвестным набором модулей, но 4 интерфейса по 1Гбит должны присутствовать. Версия ПО неизвестна, в связи с этим вопрос: а какой софт рекомендован на данный девайс? И может ли кто-то из коллег им поделиться?

 

Спасибо!

[NikBSDOpen]

Для него 12.3R6.6 надо полагать.

 

https://yadi.sk/d/Xra0-PVPcCbVn

[smart85]

Для него 12.3R6.6 надо полагать.

 

https://yadi.sk/d/Xra0-PVPcCbVn

Спасибо!

 

Приехала коробка:

1 M7I-AC-2GE-P Маршрутизатор Juniper M7I-AC-2GE-P 1

2 PE-1GE-SFP Модуль Juniper PE-1GE-SFP 2

3 PE-1GE-SFP-QPP Модуль Juniper PE-1GE-SFP-QPP 1

4 SFP-1GE-T Оптический трансивер Juniper SFP-1GE-T 4

 

Но консольника нет! Схему распайки DB-9F<->DB-9F случаем никто не знает?

Спасибо!

[NikBSDOpen]

Вроде подходит от cisco.

[smart85]

Вроде подходит от cisco.

Пробовал кошкин кабель DB9F<->Rj45 с переходником Rj45-DB9F - тишина на консоли (PuTTY serial 9600)