:strip_icc():strip_exif()/u/31285/logo2.jpg?f=community){kind=logo}
Ik heb een stuk of 8 HP 2810-48G's en 2 HP 24810-24G's.
De laatste tijd krijg ik zo nu en dan de melding (in de switchlogs, via syslog):
(Het aantal achter count: loopt steeds op).
Voor zover ik weet, is de packet buffer vol en kan de switch dan geen inkomende pakketten meer aanpakken, waardoor hij wel moet gaan droppen. Als ik de packet buffers bekijk, zie ik dat er regelmatig nog oude packets in de buffer staan. Een voorbeeldje:
Je ziet dus dat de huidige tijd 12:00:41 is, maar dat er nog pakketten in de buffer staan van 10:38. Over het algemeen zie ik de pakketten na 2 uur verdwijnen in de buffer.
Ik kan me voorstellen dat als er maar genoeg (oude) packets in de buffer staan, dat er op den duur ook geen ruimte meer is voor nieuwe packets en dat er dus gedropt moet worden op drukke tijden.
Ik dacht dat het leven van een Ethernet Frame niet lang beschoren was: eenmaal afgeleverd heeft het geen nut meer in de buffer toch?
Als ik de "Out of pkt" melding vergelijk met de andere meldingen in de switchlogs, dan zie ik dat de melding voornamelijk optreedt als machines rebooten (maakt niet uit of die machine op dezelfde switch zit of op een andere switch).
Ik heb reeds met HP gebeld maar die zeiden doodleuk dat ik de firmware moest upgraden zonder te vragen wat het probleem was (beetje eigen schuld natuurlijk, want geen care pack). Uiteraard wil ik wel upgraden, maar dat moet ik eerst plannen (downtime aankondigen, klanten op de hoogte brengen enz) dus het duurt even voordat dat uitgevoerd kan worden, dus vandaar dat ik aan het kijken ben of ik op de korte termijn het een en ander kan oplossen.
Ik heb de vraag ook al uit staan op het HP support forum, maar tot op heden geen reactie. Op dat forum vond ik wel soortgelijke meldingen, en de adviezen daar waren Mac-age timeout verhogen, QoS-settings wijzigen en dat het te maken zou hebben met een convergerende Spanning-Tree.
Volgens mij is dat laatste niet het geval (getuige de logs van alle switches). De topologie is behoorlijk statisch. Mac-age timeout staat nu op 300 (default) en dit lijkt me niet een verkeerde waarde. QoS-settings stonden default al op de aangeraden waarden.
Mijn vragen:
- weet iemand hoe het kan dat er zolang nog packets blijven staan in de buffer?
- Wat kan een reden hiervoor zijn?
- Zijn het foutieve pakketten?
- Ligt het aan de hosts?
- Moet ik de fout zoeken in de switch?
- Of is dit volledig normaal gedrag?
Ik zou graag de blijvende packets/frame willen inzien, maar dat laat de CLI van de switch niet toe.
- zijn er mogelijkheden om de inhoud van de packets die blijven staan te inspecteren zonder al te dure apparatuur?
De laatste tijd krijg ik zo nu en dan de melding (in de switchlogs, via syslog):
code:
1
| W 10/07/08 08:11:38 system: Out of pkt buffers; miss count: 216683 |
(Het aantal achter count: loopt steeds op).
Voor zover ik weet, is de packet buffer vol en kan de switch dan geen inkomende pakketten meer aanpakken, waardoor hij wel moet gaan droppen. Als ik de packet buffers bekijk, zie ik dat er regelmatig nog oude packets in de buffer staan. Een voorbeeldje:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
| pktpoolshow
Checking buffer pool structures... PASSED
total free allocated min-free missed corrupt
----- ----- --------- -------- ------ -------
MSG_BUF 1800 1754 46 1713 0 0
PKT_BUF 3072 2824 248 48 216960 0
PKT buffer pool:
Current system time: 10/10/08 12:00:41
Buffer addr OwnerName OwnerID When Allocated Lives Operation Alarm
----------- ---------- -------- ----------------- ----- --------- -----
0xa37fc0c0 bcmRX 81f51cf0 10/10/08 10:38:38 0 00000000 F
0xa366adb0 bcmRX 81f51cf0 10/10/08 10:47:39 0 00000000 F
0xa2b9b5b0 bcmRX 81f51cf0 10/10/08 10:49:58 0 00000000 F
0xa2ad65d0 bcmRX 81f51cf0 10/10/08 10:52:26 0 00000000 F
0xa2893660 bcmRX 81f51cf0 10/10/08 10:54:42 0 00000000 F
0xa2f71ea0 bcmRX 81f51cf0 10/10/08 10:57:07 0 00000000 F
0xa277f210 bcmRX 81f51cf0 10/10/08 10:58:20 0 00000000 F
0xa30f97f0 bcmRX 81f51cf0 10/10/08 10:59:34 0 00000000 F
0xa2f16a00 bcmRX 81f51cf0 10/10/08 10:59:34 0 00000000 F
0xa281daf0 bcmRX 81f51cf0 10/10/08 11:04:15 0 00000000 F
0xa36ae1f0 bcmRX 81f51cf0 10/10/08 11:07:42 0 00000000 F
0xa2f7ded0 bcmRX 81f51cf0 10/10/08 11:07:42 0 00000000 F
0xa2a26fe0 bcmRX 81f51cf0 10/10/08 11:07:42 0 00000000 F
0xa2c4f880 bcmRX 81f51cf0 10/10/08 11:11:08 0 00000000 F
0xa3a0a290 bcmRX 81f51cf0 10/10/08 11:12:18 0 00000000 F
0xa305fbf0 bcmRX 81f51cf0 10/10/08 11:12:18 0 00000000 F
0xa31cce70 bcmRX 81f51cf0 10/10/08 11:14:36 0 00000000 F
0xa32ed2f0 bcmRX 81f51cf0 10/10/08 11:14:36 0 00000000 F
0xa3cdd440 bcmRX 81f51cf0 10/10/08 11:17:39 0 00000000 F
0xa35e9210 bcmRX 81f51cf0 10/10/08 11:18:42 0 00000000 F
0xa252b590 bcmRX 81f51cf0 10/10/08 11:18:42 0 00000000 F
0xa3cc53e0 bcmRX 81f51cf0 10/10/08 11:21:00 0 00000000 F
0xa3c050e0 bcmRX 81f51cf0 10/10/08 11:23:14 0 00000000 F
0xa3db0ac0 bcmRX 81f51cf0 10/10/08 11:23:14 0 00000000 F
0xa3642040 bcmRX 81f51cf0 10/10/08 11:24:27 0 00000000 F
0xa2b2f400 bcmRX 81f51cf0 10/10/08 11:27:57 0 00000000 F
0xa28802e0 bcmRX 81f51cf0 10/10/08 11:29:07 0 00000000 F
0xa3b8cf00 bcmRX 81f51cf0 10/10/08 11:30:21 0 00000000 F
0xa3cf7b10 bcmRX 81f51cf0 10/10/08 11:30:21 0 00000000 F |
Je ziet dus dat de huidige tijd 12:00:41 is, maar dat er nog pakketten in de buffer staan van 10:38. Over het algemeen zie ik de pakketten na 2 uur verdwijnen in de buffer.
Ik kan me voorstellen dat als er maar genoeg (oude) packets in de buffer staan, dat er op den duur ook geen ruimte meer is voor nieuwe packets en dat er dus gedropt moet worden op drukke tijden.
Ik dacht dat het leven van een Ethernet Frame niet lang beschoren was: eenmaal afgeleverd heeft het geen nut meer in de buffer toch?
Als ik de "Out of pkt" melding vergelijk met de andere meldingen in de switchlogs, dan zie ik dat de melding voornamelijk optreedt als machines rebooten (maakt niet uit of die machine op dezelfde switch zit of op een andere switch).
Ik heb reeds met HP gebeld maar die zeiden doodleuk dat ik de firmware moest upgraden zonder te vragen wat het probleem was (beetje eigen schuld natuurlijk, want geen care pack). Uiteraard wil ik wel upgraden, maar dat moet ik eerst plannen (downtime aankondigen, klanten op de hoogte brengen enz) dus het duurt even voordat dat uitgevoerd kan worden, dus vandaar dat ik aan het kijken ben of ik op de korte termijn het een en ander kan oplossen.
Ik heb de vraag ook al uit staan op het HP support forum, maar tot op heden geen reactie. Op dat forum vond ik wel soortgelijke meldingen, en de adviezen daar waren Mac-age timeout verhogen, QoS-settings wijzigen en dat het te maken zou hebben met een convergerende Spanning-Tree.
Volgens mij is dat laatste niet het geval (getuige de logs van alle switches). De topologie is behoorlijk statisch. Mac-age timeout staat nu op 300 (default) en dit lijkt me niet een verkeerde waarde. QoS-settings stonden default al op de aangeraden waarden.
Mijn vragen:
- weet iemand hoe het kan dat er zolang nog packets blijven staan in de buffer?
- Wat kan een reden hiervoor zijn?
- Zijn het foutieve pakketten?
- Ligt het aan de hosts?
- Moet ik de fout zoeken in de switch?
- Of is dit volledig normaal gedrag?
Ik zou graag de blijvende packets/frame willen inzien, maar dat laat de CLI van de switch niet toe.
- zijn er mogelijkheden om de inhoud van de packets die blijven staan te inspecteren zonder al te dure apparatuur?
:strip_exif()/u/216514/sgisurf.gif?f=community)
/u/34216/avatar-60x60.png?f=community){kind=avatar}
:strip_exif()/u/12572/4-3hoek-r-b-g-g.gif?f=community)
.
Toch maar besloten om de upgrade door te zetten, om bij te blijven met de software en mocht het zich toch weer voordoen.
/u/10108/FatPie2.JPG?f=community)
. Vanuit dat perspectief is alleen het onderbrengen in een vlan niet voldoende. Ik weet dat er meerdere fabrikanten kijken naar relatief eenvoudige maar efficiente switches die dan dedicated worden ingezet voor dit soort toepassingen, juist niet het tot FC verbouwen van ethernet. Effectief heb je dan nog steeds een 'los' SAN, maar een stuk goedkoper.