[megahertz0]

Пролейте пожалуйста свет на вот какой вопрос.

Допустим у меня есть шасси WS-C65хх-E. В него втыкается несколько модулей - WS-X6748-SFP, WS-X6148V-GE-TX, WS-X6416-GBIC.

 

WS-X6748-SFP работает через фабрику, WS-X6148V-GE-TX, WS-X6416-GBIC - через шину. Теперь вопрос.

WS-X6416-GBIC или WS-X6148V-GE-TX сама обрабатывает форвардинг (л3) или постоянно дургает процессор супа (RP) а не PFC? Циска пишет что Supervisor engine CPU makes forwarding decision.

А WS-X6748-SFP как я понимаю работает через СFC (по крайней мере циска пишет Centralized CEF engine located on supervisor’s PFCх makes forwarding decision)?

Edited August 27, 2012 by megahertz0

[D^2]

WS-X6416-GBIC или WS-X6148V-GE-TX сама обрабатывает форвардинг (л3) или постоянно дургает процессор супа (RP) а не PFC?

PFC - "механизм принятия решений". именно он (в случае отсутствия DFC) и будет принимать решения куда направить очередной flow.

[agr]

Пролейте пожалуйста свет на вот какой вопрос.

Допустим у меня есть шасси WS-C65хх-E. В него втыкается несколько модулей - WS-X6748-SFP, WS-X6148V-GE-TX, WS-X6416-GBIC.

 

WS-X6748-SFP работает через фабрику, WS-X6148V-GE-TX, WS-X6416-GBIC - через шину. Теперь вопрос.

WS-X6416-GBIC или WS-X6148V-GE-TX сама обрабатывает форвардинг (л3) или постоянно дургает процессор супа (RP) а не PFC? Циска пишет что Supervisor engine CPU makes forwarding decision.

А WS-X6748-SFP как я понимаю работает через СFC (по крайней мере циска пишет Centralized CEF engine located on supervisor’s PFCх makes forwarding decision)?

 

RP не "дергает" никто. Обе "дергают" PFC, но по разному.

Edited August 27, 2012 by agr

[megahertz0]

Хоршо, кто больше тогда нагружает PFC - WS-X6748-SFP или WS-X6416-GBIC. Т.е. грубо говоря чем отличается WS-X6748-SFP от WS-X6416-GBIC кроме скорости интерконекта с коробкой и SUP? Тем что первая скажем так больше дергает PFC, а вторая меньше ввиду наличия своей CFC, которая может быть проапгрейжена до DFC?

[D^2]

Хоршо, кто больше тогда нагружает PFC - WS-X6748-SFP или WS-X6416-GBIC

не зависит от типа модуля

зависит только от количества вновь генерируемых flow через модуль

[agr]

Хоршо, кто больше тогда нагружает PFC - WS-X6748-SFP или WS-X6416-GBIC. Т.е. грубо говоря чем отличается WS-X6748-SFP от WS-X6416-GBIC кроме скорости интерконекта с коробкой и SUP? Тем что первая скажем так больше дергает PFC, а вторая меньше ввиду наличия своей CFC, которая может быть проапгрейжена до DFC?

 

PFC оба нагружают одинаково.

 

В "теоретическом" общем случае они по разному загружают общую шину, но в вашем частном случае они нагружают ее одинаково :)

 

Суть вкратце такова:

1) классические линейные карты (6416,6148) отправляют в общую шину пакет целиком в любом случае.

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

 

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

 

За подробностями собственно можете обратиться к Марксу первоисточнику http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd80673385.html

Edited August 27, 2012 by agr

[megahertz0]

ОК, спасибо за разъяснения. Все встало на свои места. Нашось время написать развернутый вопрос.

 

Ситуация у меня очень интересная. Сразу скажу, что мне уже досталось все в таком виде как есть. Я сам, честно говоря офигеваю до сих пор.

В общем, есть шеститонник в вот такой конфигурации:

 

cgw130#sh module
Mod Ports Card Type                              Model              Serial No.
--- ----- -------------------------------------- ------------------ -----------
 1   48  CEF720 48 port 1000mb SFP              WS-X6748-SFP       
 2   48  48 port 10/100/1000mb EtherModule      WS-X6148V-GE-TX    
 3   16  16 port 1000mb GBIC ethernet           WS-X6416-GBIC      
 4   16  16 port 1000mb GBIC ethernet           WS-X6416-GBIC      
 5   16  16 port 1000mb GBIC ethernet           WS-X6416-GBIC      
 6    2  Supervisor Engine 720 (Active)         WS-SUP720-3BXL     
........

Mod  Sub-Module                  Model              Serial       Hw     Status
---- --------------------------- ------------------ ----------- ------- -------
 1  Centralized Forwarding Card WS-F6700-CFC       4.1    Ok
 2  Cisco Voice Daughter Card   WS-F6K-VPWR-GE     1.1    Ok
 6  Policy Feature Card 3       WS-F6K-PFC3BXL     1.3    Ok
 6  MSFC3 Daughterboard         WS-SUP720          2.1    Ok
......

 

Как видно, есть sup720-3bxl + WS-X6748-SFP. И плюс пачка classic-модулей. Это счастье функционирует в роли ядра небольшой сетки (~130 домов). Трафик через состваляет в топе ~500 мбит дуплекс. Из роутинга в ядре есть только EIGRP с коммутаторами агрегации, парой роутеров, которые терминируют подсетки юриков, брасом и бордером. Не спрашивайте, почему был куплен шеститонник в такой бодрой конфигурации (реально бодрой) при условии, что бордер - 7206 NPE-G2, которая ну мегабит 600 дуплекса прожует если будет только роутить без слива нетфлоу. Это тайна покрытая мраком даже для меня. Но самое интересное впереди. Имхо здесь 3750 за глаза, а шеститонник в таком виде это очень навырост. Но что есть, то есть. Грехи отцов, блин, с деньгами, но без мозгов.

 

Я ядром не занимался, проблем было много других, ну работает и работает. Но кода полез - офигел. Оказывается шеститонник агрегирует оптические линки с остальных железонк не на нормальной карточке WS-X6748-SFP (не занято ни одного порта), а на пачке WS-X6416-GBIC. А серваки типа НАТа, бордер и БРАС подключены к WS-X6148V-GE-TX. Который по-сути те же дрова, да еще и с модулем inline power (даже не 802.3af) который в коммутаторе ядра не вперся нафиг.

 

В общем, решил я все эту сетку переводить на IPoE, поднял БРАС с ISG и NAT на отдельной машине, прикрутил все к биллингу, понял нормальный внутрисетевой роутинг. И заметил вот какой момент. Т.к. БРАС заработал нормально и шейпер на нем стал шейпить более-менее ровно, а не показывать погоду на Марсе, трафик вырос раза в полтора. Загрузка проца у шеститонника в пике стала подпрыгивать до 30%. Это при трафике в 500 мбит. Т.е. пока он просто комутировал - было все более менее хорошо. Вылизывание конфига и обновление иоса (стояла какая-то древняя версия, еще и от 7600 O_0) снизило нагрузку до 15% в пике. При этом шеститонник ничего не делает кроме обычного роутинга, который у него железный. НАТ, шейпер, бордер - отдельные железки.

 

В общем вот что в процессах

cgw130#sh proc cpu sort
cgw130#sh proc cpu sorted 5m
CPU utilization for five seconds: 8%/6%; one minute: 9%; five minutes: 9%
PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
264    28486156 211460677        134  0.39%  0.41%  0.42%   0 IP Input
465    27206632 177554286        153  0.79%  0.40%  0.39%   0 Port manager per
  9    23095844   1468497      15727  0.00%  0.27%  0.28%   0 Check heaps
 12     7400564  26849877        275  0.15%  0.22%  0.23%   0 ARP Input
 24    16304908 184444368         88  0.00%  0.16%  0.20%   0 IPC Seat Manager
285       27636 922645495          0  0.15%  0.15%  0.15%   0 Ethernet Msec Ti
342     2561740  10784183        237  0.07%  0.10%  0.09%   0 CEF: IPv4 proces
258      995728   5785698        172  0.07%  0.07%  0.07%   0 CDP Protocol
 51      137088   7300217         18  0.07%  0.07%  0.07%   0 Per-Second Jobs
515     3132456  12034753        260  0.07%  0.05%  0.05%   0 SNMP ENGINE
363     2595812   3640762        712  0.07%  0.04%  0.05%   0 HIDDEN VLAN Proc
301     2326124   2183092       1065  0.07%  0.04%  0.05%   0 QOS Stats Gather
 52     4494240    135647      33132  0.00%  0.07%  0.05%   0 Per-minute Jobs
432     4000364  24576729        162  0.07%  0.04%  0.02%   0 RPC online_diag_
392       24924 226926846          0  0.00%  0.02%  0.01%   0 RADIUS
 80          68       163        417  0.00%  0.01%  0.00%   1 Virtual Exec
464       10276  85799972          0  0.07%  0.02%  0.00%   0 PM Callback
524     1680240  17616693         95  0.07%  0.02%  0.00%   0 NTP
505      338740   4215659         80  0.07%  0.00%  0.00%   0 PDU DISPATCHER
462     1041548   8432818        123  0.07%  0.01%  0.00%   0 IP SNMP
527      423268  12898748         32  0.00%  0.01%  0.00%   0 EIGRP-IPv4 Hello
529        3640  29137373          0  0.00%  0.01%  0.00%   0 MLD
 23           0         1          0  0.00%  0.00%  0.00%   0 IPC Process leve
 17         560      6442         86  0.00%  0.00%  0.00%   0 EEM ED Syslog
 25           0         1          0  0.00%  0.00%  0.00%   0 IPC Session Serv
 26           0         1          0  0.00%  0.00%  0.00%   0 IPC Stdby Update
 27           0         2          0  0.00%  0.00%  0.00%   0 DDR Timers
 28           0         2          0  0.00%  0.00%  0.00%   0 Dialer event
 29           0         1          0  0.00%  0.00%  0.00%   0 ifIndex Receive
 30           0         2          0  0.00%  0.00%  0.00%   0 Serial Backgroun
 31           0         1          0  0.00%  0.00%  0.00%   0 Crash writer
 32      497764   3878448        128  0.00%  0.00%  0.00%   0 EnvMon

 

IP Input в топе и есть мнение, что часть трафика не обрабатывается CEF.

 

Вот статистика:

 

cgw130#sh ip cef switching statistics

      Reason                          Drop       Punt  Punt2Host
RP LES No route                        1547          0         24
RP LES Packet destined for us             0   29654754          0
RP LES No adjacency                12871274          0          0
RP LES Incomplete adjacency              45          0          0
RP LES Unresolved route                3549          0          0
RP LES Bad checksum                      89          0          0
RP LES TTL expired                        0          0     909844
RP LES Bad IP packet length               1          0          0
RP LES Routed to Null0             39168829          0          0
RP LES Features                    16323329        934    4215787
RP LES IP redirects                       0          0    7239401
RP LES Unclassified reason               11          0          0
RP LES Neighbor resolution req      2898763        636          0
RP LES Total                       71267437   29656324   12365056

All    Total                       71267437   29656324   12365056

 

В общем, есть мнение, что виною выпадания трафика в process switching является использование classic-карточек, которые l2-коммутацию выполнят не затрагивая SUP, а с l3 у них туго. Плюс еще есть PBR, который на них неизвестно как работает, хотя циска и говорит, что он железный. No ip redirects и no ip unreachables включен на всех SVI.

Соответственно есть желание сдать в металлолом все classic-карточки, пересадить отические линки на нормальный модуль с SFP, а для медных гигабитов поставить WS-X6748-GE-TX (c cef720) или WS-X6548-GE-TX (с cef256). Собственно разница в ценнике между модулями с cef720 и cef256 почти в 2 раза и соответственно не понятно есть ли смысл переплачивать за модуль при условии, что его производительности хватит за глаза в ближайшем обозримом будущем.

[agr]

500M L3 трафика даже с картой 6148 ваш шеститонник должен пережевать не поперхнувшись. Надо искать причину высокой загрузки проца. Если заменить карты, то она может и не исчезнуть. Надо смотреть, что за трафик идет на обработку процессором.

[nnm]

PBR там железный при соблюдении некоторых условий: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/layer3.html#wp1027016

 

И от типа линейной карты не зависит.

[g3fox]

Трафик может попадать на проц. Если это трафик который предназначен самому коммутатору.

 

Платы CEF256 работают с фабрикой на скорости 8gbit.

Тоесть если вы захотите использовать платы с 16-ю 1Г портами, переподписка будет 200%.

Лучше с ними не связываться.

 

Вообще вы можете использовать шеститонник с 3bxl даже как бордер. Он легко уместит в себе FV если у вас памяти 1Г.

[agr]

У человека 500М трафика всего, а загрузка проца до 30% - это очень много при таких условиях и от типа карт скорее всего не зависит. megahertz0, ищите что за трафик идет на обработку процу. Обратите особое внимание идет ли какой-либо мультикаст трафик на роутер - это наиболее частая причина высокой загрузки процессора.

Edited August 28, 2012 by agr

[Дятел]

Вижу проц 9%, 30 не вижу...

 

 

Линейные карты 6416 - нормальное решение для агрегации, используем массово. Только с сап32, а сап 720, как у вас - используется как бордер, там уже платы 67хх, 10Г и SFP.

[agr]

Вижу проц 9%, 30 не вижу...

 

В выводе команды 9, но ТС писал

Загрузка проца у шеститонника в пике стала подпрыгивать до 30%. Это при трафике в 500 мбит.

[Дятел]

Это я к тому, что интересна разблюдовка по-процессам именно когда 30%, а около 10 процентов будет показывать, наверное, даже сап без модулей ....

[megahertz0]

К сожалению 30% так и не удалось выжать после чистки конфига. Как-то не догадался sh proc cpu посмотреть в этот момент. Сейчас средняя нагрузка за день по мониторингу - 3%, максимум - 6%.

 

Вообще вы можете использовать шеститонник с 3bxl даже как бордер. Он легко уместит в себе FV если у вас памяти 1Г.

1М записей в TCAM как бы располагает:).

[DVM-Avgoor]

Что-то явно не так.

 

Хламовый SUP2 + WS-X6516-GBIC для L3 агрегации и небольшой сетки (3к хостов, ACL, бгп 1к роутов)

 

c6509#sh mls statistics

Statistics for Earl in Module 1

L2 Forwarding Engine
 Total packets Switched                : 5847248446110

L3 Forwarding Engine
 Total Packets L3 Switched             : 5847248446110 @ 457077 pps

 Total Packets Bridged                 : 35630670228
 Total Packets FIB Switched            : 5088222613506
 Total Packets ACL Routed              : 672135673876
 Total Packets Netflow Switched        : 0
 Total Mcast Packets Switched/Routed   : 50389225001
 Total ip packets with TOS changed     : 66870970
 Total ip packets with COS changed     : 12441
 Total non ip packets COS changed      : 0
 Total packets dropped by ACL          : 293907838
 Total packets dropped by Policing     : 0
 Total Unicast RPF failed packets      : 0

Errors
 MAC/IP length inconsistencies         : 10636052
 Short IP packets received             : 749
 IP header checksum errors             : 2692031
 MAC/IPX length inconsistencies        : 127
 Short IPX packets received            : 59

Total packets L3 Switched by all Modules: 5847248446110 @ 457077 pps

CPU utilization for five seconds: 5%/2%; one minute: 5%; five minutes: 6%
PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
116   3858311202093111525        184  1.35%  1.12%  1.23%   0 IP Input
261    71127060 445484225        159  0.55%  0.22%  0.18%   0 Port manager per
  9   168871732 838375842        201  0.47%  0.56%  0.52%   0 ARP Input
162    39587260  12061644       3282  0.23%  0.15%  0.14%   0 IPC LC Message H
108         416      1369        303  0.23%  0.20%  0.07%   1 Virtual Exec
157    27108180   6523704       4155  0.15%  0.10%  0.08%   0 Adj Manager
122    21200316  71536625        296  0.07%  0.08%  0.07%   0 ARP HA

 

Так что 500Мбит для вашей бандуры вообще не нагрузка.

[rdntw]

вопрос по 6748 CFC.

кто-нибудь поднимал mpls/rsvp на L3 Port-channel?

До этого все работало на одном физическом L3 линке в такой конфигурации

interface GigabitEthernet7/23
mtu 1586
ip address 185.XX.115.77 255.255.255.252
ip ospf 1 area 0
mpls traffic-eng tunnels
mpls ip
ip rsvp signalling hello
end

 

Решил расширить канал сделав

 

interface GigabitEthernet7/23
mtu 8986
no ip address
channel-group 15 mode active
end

WS6509-Med5#sh run int g7/24
Building configuration...

Current configuration : 92 bytes
!
interface GigabitEthernet7/24
mtu 8986
no ip address
channel-group 15 mode active
end

interface Port-channel15
mtu 8986
ip address 185.XX.115.77 255.255.255.252
ip ospf 1 area 0
mpls ip
ip rsvp signalling hello
end

 

Думаю дело в команде "mpls traffic-eng tunnels" которая "не вводится" в PO15.

По докам не нашел поддерживается ли MPLS на L3 LAG-ах. У кого был опыт?

 

сейчас пока писал дошло может сначала прописать "mpls traffic-eng tunnels" на линках входящих в состав PO15

[rdntw]

up :)

[dazgluk]

Попробуйте использовать Interface vlan и l2 etherchannel

[SyJet]

Ребят, чтоб не плодить, не вкурю по модулям с гбиками 6516А и просто 6516, как я понимаю разница только в буферах? Получается что с буквой А предпочтительней?

[rdntw]

Попробуйте использовать Interface vlan и l2 etherchannel

насколько я понял, чтоб поднимать mpls-соседство на дешевых картах, порт должен быть в routed-mode.

но, ок, проверю на svi.

[dazgluk]

Попробуйте использовать Interface vlan и l2 etherchannel

насколько я понял, чтоб поднимать mpls-соседство на дешевых картах, порт должен быть в routed-mode.

но, ок, проверю на svi.

Как минимум на фабричных 67ХХ модулях и SUP720-3B все отлично поднимается

interface Vlan3001
description 7600-ASAF-6504-mpls
mtu 9216
bandwidth 10000000
ip address 172.25.78.22 255.255.255.252
ip pim sparse-mode
mpls mtu 1546
mpls traffic-eng tunnels
mpls ip

[catalist]

Ребят, чтоб не плодить, не вкурю по модулям с гбиками 6516А и просто 6516, как я понимаю разница только в буферах? Получается что с буквой А предпочтительней?

да

[rdntw]

Как минимум на фабричных 67ХХ модулях и SUP720-3B все отлично поднимается

Спасибо! На SVI соседство поднялось. В связи с этим "шаблоны порвались" и теперь думаю как лучше сделать

 

например есть 3 65х в кольце, есть 2 возможности поднять MPLS

1) на L3-routed портах между ними

2) на SVI

 

2й способ более гибкий тк позволит пробрасывать чистый L2 помимо MPLS L2VPN. А есть еще какие-то плюсы/минусы того и другого способа?

где-то читал что чистый L3 порт работает быстрее чем эмулируемый svi, но может это не относится к 65м.

[sol]

где-то читал что чистый L3 порт работает быстрее чем эмулируемый svi, но может это не относится к 65м.

Что тот, что этот железный и Wire Speed. Более того, это L3 эмулируется. И на эту эмуляцию тратится один Vlan.