[shicoy]

В одном решении сабж использует как пограничный коммутатор, с двумя FV. Как бы работает все хорошо, до момента когда суммарный трафик превышает 2Гбит/сек (соотношение примерно 55% вход и 45% исход). После чего рост скорости замедляется, скорость скачивания с инет-ресурсов падает в разы (например тот же спидтест).

 

В качестве интерфейсных портов, используются порты на управляющей плате.

system-max ip-cache 400000
system-max ip-filter-sys 8096
system-max ip-route 400000
system-max session-limit 1000000

#show cpu
3 percent busy, from 794 sec ago
1   sec avg:  5 percent busy
5   sec avg:  2 percent busy
60  sec avg:  2 percent busy
300 sec avg:  3 percent busy

#show processes cpu
Process Name   5Sec(%)   1Min(%)   5Min(%)   15Min(%)   Runtime(ms)
ACL              0.00      0.00      0.00      0.00              0
ARP              0.00      0.00      0.00      0.00           7306
AT               0.00      0.00      0.00      0.00              0
BGP              0.06      0.03      0.03      0.04         704579
DOT1X            0.00      0.00      0.00      0.00              0
GVRP             0.00      0.00      0.00      0.00              0
ICMP             0.00      0.00      0.00      0.00          13576
IP               6.67      9.41      9.37      7.96      102641129
IP_M             0.00      0.00      0.00      0.00           4415
IPUP             0.11      0.03      0.02      0.03         181250
IPX              0.00      0.00      0.00      0.00              0
L2VLAN           0.00      0.00      0.00      0.00          92823
NAT              0.00      0.00      0.00      0.00              0
OSPF             0.92      1.14      1.16      1.02       10656335
RIP              0.00      0.00      0.00      0.00           1204
STP              0.00      0.00      0.00      0.00              0
VRRP             0.00      0.00      0.00      0.00              0

#show memory
Total DRAM: 536813568 bytes
 Dynamic memory: 509550588 bytes total, 257116768 bytes free, 49% used
     BGP memory: 75106080 bytes (14%) used from dynamic memory
    OSPF memory: 2235400 bytes (<1%) used from dynamic memory
SSH@border.main.cheb#show memory tcp
TCP MEMORY USAGE
TCB usage: total=229401, free=226529
TCP QUEUE BUFFER usage: total=224183, free=223964
TCP SEND BUFFER usage: total=1534500, free=1528500
TCP RECEIVE BUFFER usage: total=3070500, free=3070500
TCP OUT OF SEQUENCE BUFFER usage: total=23084, free=23084

на всех портах
no flow-control

 

куда копать? Что не так..

[shicoy]

Вопрос для знающих, сколько трафика может пропустить через себя модуль J-BxGMR4 при условии что принимает на себя 1 Full View BGP + еще около 100к маршрутов по BGP?

Где-то проскакивала инфа что не более 1,5Гбит/сек на вход.

Есть у кого опыт использования?

[caz]

8 гигабит на слот фулл дуплекса, т.е. 16 халф. стоят агрегаторы, на районах, там уже давно больше 1,5 гигабит.. да и бордер был на jetcore, 6,5-7 прокачивал легко с 2-3 FV

[shicoy]

Остается открытым вопрос, где засада.

[alex_001]

CAm'ов не хватает возможно , лечится втыканием еще 1 модуля и раскидыванием линков на него.

[nashvill]

У J-BXGMR4 shared cam'ы. Паска камов на первые 4 порта и пачка камов на вторые 4 порта.

Как показал опыт, лучше работает, когда аплинки в первой четверке, даунлинки во второй.

[shicoy]

У J-BXGMR4 shared cam'ы. Паска камов на первые 4 порта и пачка камов на вторые 4 порта.

Как показал опыт, лучше работает, когда аплинки в первой четверке, даунлинки во второй.

У меня именно так. Но на downlink собран LAG, видимо он сильно жрет кам, поэтому буду ставить доп.плату и смотреть.

 

Кстати посоветуйте как еще разбить кам на шасси которое делает:

ospf а узлам агрегации l3 (30 узлов) и по l2 приземляет порядка 500 маков.

[alex_001]

У J-BXGMR4 shared cam'ы. Паска камов на первые 4 порта и пачка камов на вторые 4 порта.

Как показал опыт, лучше работает, когда аплинки в первой четверке, даунлинки во второй.

У меня именно так. Но на downlink собран LAG, видимо он сильно жрет кам, поэтому буду ставить доп.плату и смотреть.

 

Кстати посоветуйте как еще разбить кам на шасси которое делает:

ospf а узлам агрегации l3 (30 узлов) и по l2 приземляет порядка 500 маков.

 

CAM к ospf отношения не имеют , под L2 наверное минимум оставить - 500 маков весьма немного.

[shicoy]

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

[Helios]

Была похожая трабла.. включали debug hw, а там по show backplane сплошные WriteDrop. LAG надеюсь собран статиком, нам немного помог вынос всех LAG на отдельный J-B16GX в первый слот (с проца все убирали). Балансинг src-dst IP, если добавляли еще ports, становилось еще хуже. Долго мучались, сейчас поставили в том же кач-ве Extreme X480. Foundry стоит на полке..

[shicoy]

Была похожая трабла.. включали debug hw, а там по show backplane сплошные WriteDrop. LAG надеюсь собран статиком, нам немного помог вынос всех LAG на отдельный J-B16GX в первый слот (с проца все убирали). Балансинг src-dst IP, если добавляли еще ports, становилось еще хуже. Долго мучались, сейчас поставили в том же кач-ве Extreme X480. Foundry стоит на полке..

WriteDrop тоже наблюдаются. Чем лечить?

[Helios]

имхо только танцами с бубном. брали отдельную платку J-B16GX и экспериментировали " а что будет если поставить ее в слот 1, на ней 4 порта в сторону клиентов, а 4 на процессорной плате в сторону инета. Потом в слот 3 переставляли - аналогично проверяли.." Лучшие результаты в нашем варианте получались когда все транки собирались в 1 слоте. софт ver 08.0.01sT53, последний 08.0.01w подтупливал. теор. базы на этот счет нигде нет, обосновать методы не могу.

Изменено 16 октября, 2011 пользователем Helios

[shicoy]

08.0.01s виснут 10G модули, с 08.0.01w постабильнее.

Вообщем понятно, что Foundry в помойку. Потому что такая ситуация с write drop на всех фаундри. Причем даже там где просто ip routing без всяких lag.

 

ps. Все же не понятно, достаточно серьезная железка, не особо под какой-то большой нагрузкой работает и такие косяки :(

[PowerPack]

Ничего на Foundry Не виснет и тем более модули 10G. У вас видать глючное железо попалось, может шасси тупит? Покажите sho cam ip 1/1 stat и.т.д. по всем портам.

 

У нас сейчас на бордере стоит такое железо - J-BxGMR4 в пиках лопатит 5 гигабит полного дуплекса (3 аплинка с агрегировнием по /21), загрузка процессора при этом 50%. CAM только узкое место - раскидали по разным платам - живет нормально.

Изменено 13 ноября, 2011 пользователем PowerPack

[caz]

Ничего на Foundry Не виснет и тем более модули 10G. У вас видать глючное железо попалось, может шасси тупит? Покажите sho cam ip 1/1 stat и.т.д. по всем портам.

 

У нас сейчас на бордере стоит такое железо - J-BxGMR4 в пиках лопатит 5 гигабит полного дуплекса (3 аплинка с агрегировнием по /21), загрузка процессора при этом 50%. CAM только узкое место - раскидали по разным платам - живет нормально.

 

cpu у вас какой-то большой, ip load-sharing отключили? пробывали с ip net-aggregate разгрузить cam?

 

Где-то проскакивала инфа что не более 1,5Гбит/сек на вход.

Есть у кого опыт использования?

 

неправда :)

10GigabitEthernet14/1 is up, line protocol is up
 MTU 1518 bytes, encapsulation ethernet
 300 second input rate: 2204392064 bits/sec, 300217 packets/sec, 22.48% utilization
 300 second output rate: 1807667936 bits/sec, 281864 packets/sec, 18.49% utilization

sh cpu
5 percent busy, from 20410 sec ago
1   sec avg:  1 percent busy
5   sec avg:  1 percent busy
60  sec avg:  1 percent busy
300 sec avg:  1 percent busy

 

sh mac-address
Total active entries from all ports = 4638

 

правда используется не как бордер, а как агрегатор района, но когда jetcore был боррдеторм то проблем не возникало на таких скоростях.

[alex_001]

Еще хороший способ Foundry убить по cpu usage - включить где нибудь ACL на out - они софтовые. Причем необязательно этот ACL должен висеть на чемто сильно используемом - достаточно чтобы он был на порту с высокой загрузкой (т.е например есть vlan1 , vlan2 , на vlan1 вешаем out acl и оба vlan'a закидываем на 1 порт. после получаем переполнение L4 cam и большой cpu usage если в vlan2 достаточно траффика , хотя на vlan2 и нет ничего).. Собственно это дело в документации гдето было описано.

 

Вобщем не похоже на данный случай , но проверить стоит.

[PowerPack]

8 гигабит на слот фулл дуплекса, т.е. 16 халф. стоят агрегаторы, на районах, там уже давно больше 1,5 гигабит.. да и бордер был на jetcore, 6,5-7 прокачивал легко с 2-3 FV

 

Откуда инфа? По моим данным у линейки JetCore 20 гигабит фул дуплекса на слот. Они ведь все wire speed заявляют, а там есть платы 2 порта 10GE.

 

P.S. Изучил документацию, получается 256 гигабит на 8 слотовое шасси, итого 32 гигабита на слот (у 4 слотового шасси 128 гигабит на шасси).

Изменено 14 ноября, 2011 пользователем PowerPack

[caz]

8 гигабит на слот фулл дуплекса, т.е. 16 халф. стоят агрегаторы, на районах, там уже давно больше 1,5 гигабит.. да и бордер был на jetcore, 6,5-7 прокачивал легко с 2-3 FV

 

Откуда инфа? По моим данным у линейки JetCore 20 гигабит фул дуплекса на слот. Они ведь все wire speed заявляют, а там есть платы 2 порта 10GE.

из JetCore™ Based Chassis Systems (An Architecture Brief on NetIron, BigIron, and FastIron Systems)

The switch fabrics of all chassis were designed with ample bandwidth capable of serving all interface module slots simultaneously at full speed without any blocking (offering each interface slot an 8 Gbps feed into it, and 8 Gbps out of it).

 

да и на AMS-IX есть документация, там тоже про это писали.

 

хотя я может чего-то не допонял..

[ArcticFox]

Как правильно собрать аггрегацию, чтобы CPU не грузило? Не стоит ли перекинуть на FWD карточку?

[ArcticFox]

UPD: как увеличить таблицу маршрутов более 400к? Возможно ли это?

[shicoy]

Как правильно собрать аггрегацию, чтобы CPU не грузило? Не стоит ли перекинуть на FWD карточку?

No ip load share

Больше 400к нельзя, на практике больше 200к не стоит

[ArcticFox]

Что делать если надо передать full-view?

Сжать таблицу через ip net-aggregate или через ip supernet реально?

Надо принимать и отдавать full-view.

 

Если за ночь не запустится, заменю на 7201.

[xcme]

...пробывали с ip net-aggregate...?

 

Спасибо за команду. В ряде случаев сбросило нагрузку с 30% до 1%.