[tehmeh]

По моей проблеме - растут overrun, когда входящая нагрузка на интерфейсе за 8.2G.

Интересует два вопроса:

 Hardware is SPA-1X10GE-L-V2
 Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0

Стоит ли пробовать играть с hold-queue? Какие лучше выставить значения, 2000? Если на работающем интерфейсе прописывать, не прервется передача?

 

И второй вопрос, если overrun возникает из-за перегруза интерфейса, есть смысл перекоммутировать линк в L3 коммутатор с большими буферами, с которого до ASR собрать LACP. Имеет ли смысл?

 

router#show platform 
Chassis type: ASR1004             

Slot      Type                State                 Insert time (ago) 
--------- ------------------- --------------------- ----------------- 
0         ASR1000-SIP40       ok                    3w2d          
0/0      SPA-1X10GE-L-V2     ok                    3w2d          
0/1      SPA-1X10GE-L-V2     ok                    3w2d          
0/2      SPA-1X10GE-L-V2     ok                    3w2d          
0/3      SPA-1X10GE-L-V2     ok                    3w2d          
R0        ASR1000-RP2         ok, active            3w2d          
F0        ASR1000-ESP40       ok, active            3w2d          
P0        ASR1004-PWR-AC      ok                    3w2d          
P1        ASR1004-PWR-AC      ok                    3w2d          

Slot      CPLD Version        Firmware Version                        
--------- ------------------- --------------------------------------- 
0         00200800            15.4(2r)S                           
R0        13092401            15.4(2r)S                           
F0        1003190E            15.4(2r)S                           
router#

[tehmeh]

Ну что, похоже подтверждаю проблему у себя на 1004.

 

В железке 4 10G интерфейса, которые раскиданы по двум L2 LAG, один приходящий после SCE (nat inside), второй (nat outside) уходит в сторону коммутатора, собирающего каналы апстримов и ix.

 

Ошибки в ЧНН начинают копиться на физических интерфейсах, собранных в LAG, где есть nat outside sub-интерфейсы. На in-band управлении, который заводится также через этот LAG, в это время растут задержки. Так же они растут и для трафика абонентов. По моим наблюдениям иногда до 60 ms.

По графикам нагрузки на QFP видна характерная полка на 60% в это же время, трафик (non-priority), проходящий через QFP, упирается в полку на отметке 16G.

Через железо ходят и реальники, и nat, посчитать нагрузку последних отдельно не могу (не знаю как). Но думаю там до 8G.

 

При том что ESP на 40G, все это очень грустно. Есть идеи?

[zhenya`]

SIP какой ?

[tehmeh]

Сверху скидывал show platform. Установлен SIP40.

[zhenya`]

netflow ?

[tehmeh]

Есть немного, снимается на sub-интерфейсе, который висит на входящем LAG, который после SCE. Ошибки на интерфейсах другого LAG.

 

Сегодня в ЧНН прихлопну netflow на часик, не критично.

[zhenya`]

давайте конфиг интерфейсов чтоли.. zbf и прочего нет ?

[tehmeh]

Нет, zbf нет.

 

Конфиг интерфейсов до невозможности простой.

 

interface TenGigabitEthernet0/0/0

no ip address

no ip redirects

no ip unreachables

no ip proxy-arp

channel-group 2 mode active

end

 

interface TenGigabitEthernet0/1/0

no ip address

no ip redirects

no ip unreachables

no ip proxy-arp

channel-group 2 mode active

end

 

interface TenGigabitEthernet0/2/0

no ip address

no ip redirects

no ip unreachables

no ip proxy-arp

channel-group 1 mode active

end

 

interface TenGigabitEthernet0/3/0

no ip address

no ip redirects

no ip unreachables

no ip proxy-arp

channel-group 1 mode active

end

 

interface Port-channel1

no ip address

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat inside

load-balancing flow

end

 

interface Port-channel2

no ip address

no ip redirects

no ip unreachables

no ip proxy-arp

no ip address

end

 

Дальше идет куча sub-интерфейсов.

Всего один на port-channel 1, входящий от SCE. Остальные на проблемном port-channel 2, которые терминируют VLAN с апстримами, ix, ibgp от ядра. Их куча, конфиг абсолютно идентичный за исключением адресов.

 

interface Port-channel1.53 !входящий после SCE

encapsulation dot1Q 53

ip address x.y.z.w 255.255.255.248

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat inside

ip flow monitor NF-MONITOR input

ip flow monitor NF-MONITOR output

end

 

interface Port-channel2.30 !один из апстримов (остальные такие же)

encapsulation dot1Q 30

ip address x.y.z.w 255.255.255.252

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat outside

end

 

Единственная "сложность" это IX-вые sub-интерфейсы с раут-мапом, чтобы трафик ходил мимо SCE через Port-Channel 2 по iBGP-линку в ядро.

 

interface Port-channel2.35

description iBGP

encapsulation dot1Q 35

ip address 10.0.0.2 255.255.255.252

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat inside

end

 

interface Port-channel2.18

description IX1

encapsulation dot1Q 18

ip address x.y.z.w 255.255.255.252

ip nat outside

ip policy route-map GO-DIRECT-7600

end

 

route-map GO-DIRECT-7600 permit 10

set ip next-hop 10.0.0.1

!

 

[zhenya`]

попробуйте еще снять ip policy route-map. Может поможет

[tehmeh]

SCE тогда завернет, она по документам на 15G рассчитана, если мы через нее IX подадим, то service loss обеспечен : (

[alks]

SCE тогда завернет, она по документам на 15G рассчитана, если мы через нее IX подадим, то service loss обеспечен : (

 

бошку вторую в sce докупать надобно ))

[tehmeh]

Да ну ее : )

Переводим на нормальный BRAS.

[alks]

Да ну ее : )

Переводим на нормальный BRAS.

 

в смысле? функции dpi переводите на брас или сейчас sce используете как брас?

[tehmeh]

От DPI разве что p2p в ЧНН подрезать, в чем потребности давным давно нет.

Сейчас она просто полисит полосу абоненту, фильтрует URL и пускает/не пускает.

 

Полисинг, редирект на ЛК, блокировку доступа переносим на полноценный брас постепенно, плюс терминацию абонентских VLAN с каталистов сводим на qinq в брас. А SCE в будущем будет просто URL фильтровать, или поедет на склад/барахолку/etc.

[tehmeh]

По своей проблеме. Предварительные данные такие. Отключение netflow в ЧНН убило 15% нагрузки на QFP: c 60 стало 45.

По графику latency упало с 28 ms до адекватных 0.4 ms.

 

Трафик, конечно, сильно не возрос, но небольшой рост заметен. Так как ЧНН только-только началось, видимо, будет еще расти.

[darkagent]

Отключение netflow в ЧНН убило 15% нагрузки на QFP: c 60 стало 45.

это классический netflow, или FNF ?

[tehmeh]

Отключение netflow в ЧНН убило 15% нагрузки на QFP: c 60 стало 45.

это классический netflow, или FNF ?

FNF судя по всему (есть flow record, flow exporter в конфиге), не я настраивал, в нетфлоу не силен.

[alks]

емнип память для флоу и нат трасляций одна и таже

[alks]

вот посмотрите доку https://clnv.s3.amazonaws.com/2014%2Fusa%2Fpdf%2FBRKARC-2019.pdf?Signature=LXhjE6CMMADFz2TWnq6jMWbOHSI%3D&AWSAccessKeyId=AKIAJO3XQSJMRXKWDHZQ&Expires=1442246010

 

nat session && cache flow лежат в resource DRAM

 

смотреть show platform hardware qfp active infrastructure exmem statistics

там же и мибы есть

включите netflow посмотрите что там чнн будет

[tehmeh]

Спасибо за информацию, я как раз искал способы мониторинга таких ситуаций, так как рано или поздно все равно туда же придем и без netflow.

 

Спасибо, zhenya`, за наводку также.

Изменено 14 сентября, 2015 пользователем tehmeh

[alks]

Да там дока нормальная, ключевая картинка http://clip2net.com/s/3nsvXUh

[zhenya`]

даже без ната на стандартном конфиге FNF (без правки размера кэша, таймаутов и т.д.) ловил оверраны (и возросшие пинги) при цифре трафика около 13 гбпс (суммарного) на есп40..

 

спасибо за доку.

Изменено 14 сентября, 2015 пользователем zhenya`

[tehmeh]

Увеличили пул в два раза, сократили в половину кол-во max-entries.

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

[alks]

Увеличили пул в два раза, сократили в половину кол-во max-entries.

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

 

красивый график получился, если в rrd то скинь скриптик отрисовки и список ойдов, лень самому делать )))

[tehmeh]

oid'ами поделюсь:

1.3.6.1.4.1.9.9.715.1.1.7.1.15.9037.1 lowest watermark

1.3.6.1.4.1.9.9.715.1.1.7.1.13.9037.1 free mem

1.3.6.1.4.1.9.9.715.1.1.7.1.11.9037.1 in use

1.3.6.1.4.1.9.9.715.1.1.7.1.9.9037.1 total (fre + used)

 

А строим заббиксом)