Newsgroup: it.comp.reti.cisco
Titolo: high cpu sul 4500 a causa di traffico multicast

Ciao,
sto affrontando un problema di uso eccessivo della cpu su un cisco
4507....
show proc cpu sorted
27  1950528116 208559774       9352 34.71% 36.02% 35.93%   0 Cat4k
Mgmt LoPri
show platform health
K2CpuMan Review  30.00  41.78     30     76  100  500   46  50   12
39079:50
show platform cpu packet statistics
ACL fwd(snooping)            189403029       627       549
428        146
e via di seguito fino a comprendere che il problema di cpu alta deriva
da un server ubuntu che genera traffico multicast con dst adddres
224.0.0.56.
Se spengo l'interfaccia del 4500 verso il server ubuntu il consumo di
cpu si riduce del tutto. Ok.
Quello che non riesco a capire è perché se creo un access-list che
blocca quel traffico al livello di switched virtual interface il
consumo di cpu *non* si riduce, come se la cpu fosse comunque
costretta a processare il multicast.
ip access-list extended vlan100-in
10 deny ip host 192.168.10.99 host 224.0.0.56
20 permit ip any any
interface vlan 100
ip add 192.168.10.1 255.255.255.0
ip access-group vlan100-in in
Che ne pensate?
ciao!


Ciao Marco,
  credo che la scelta del gruppo verso cui trasmette il server sia
stata poco felice...
Quoto dalla documentazione:  (
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/52sg/configuration/guide/mcastmls.html#wp1082100
)
"The following packets are always forwarded in software:
•Packets sent to multicast groups that fall into the range 224.0.0.*
(where * is in the range from 0 to 255). This range is used by routing
protocols. Layer 3 switching supports all other multicast group
addresses.  "
Tra l'altro il range 
224.0.0.0/24
  e' chiamato Reserved Link-Local
Addresses, il traffico destinato a questi gruppi non viene forwardato,
ma processato in locale.
Se il traffico multicast deve rimanere all'interno della tua
organizzazione, ti consiglierei di usare un indirizzo Limited Scope
( 
239.0.0.0/8
 ).
Puoi trovare una tabella con i vari range di indirizzi multicast qui:
http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_tech_oview_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1054899
HTH
Marco
--
Marco Rizzi
home: 
http://rizzitech.blogspot.com

 Puoi trovare una tabella con i vari range di indirizzi multicast qui:
http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_t
.

 
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sga/.
..

Ciao Marco,
ma che simpatico questo bug di pulseaudio!
guardando il dump del traffico generato, noto che ha TTL=1.
Questo mi fa pensare che sia in ogni caso processato dalla cpu,
anche se l'acl come l'hai messa tu dovrebbe andare in hardware.
Per quanto riguarda il tuo esempio con eigrp, credo che il traffico
sarebbe processato in cpu, sempre a causa del ttl=1 e poi il deny
dell'acl impedirebbe l'adiacenza, ovviamente in questo caso l'impatto
di un hello e' trascurabile, mentre probabilmente il tuo server
"spara" molto piu' traffico.
Credo purtroppo che la soluzione in questo caso, per ridurre il
consumo di cpu pur avendo applicato l'acl, sia il classico "isolate
the traffic source" :-(
HTH
Marco Rizzi



Infatti, è la soluzione messa in atto.:-) Poi lo stop del demone
pulseaudio sul server incriminato.
Grazie di tutto Marco!



di nulla, you're welcome!
(tra l'altro siamo anche colleghi...) :-)


 Marco Rizzi
Eh si! ;-)    io roma tu trento. :-)
