Dlaczego otrzymujemy dużą fluktuację pomiaru pasma Wykres kaktusów?

Byliśmy w teście redundancji Etherchannel i routingu w naszej sieci. Podczas tej interwencji dokonaliśmy pomiaru. Naszym narzędziem do monitorowania są kaktusy do wykresów. Monitorowany sprzęt to 4500-X na VSS. Każde łącze znajduje się na innym fizycznym podwoziu.

Schemat:

Chronologia testu:
[t0] Link na porcie te1 / 1/14 został fizycznie usunięty. Te2 / 1/14 jest aktywny. Po1 działa.
[t0 + 15] Link do portu Te1 / 1/14 powrócił do pracy i sprawdził, czy port z powrotem w kanale ether Po Po
[t0 + 20] Link do portu te1 / 1/14 został fizycznie usunięty. Te2 / 1/14 jest aktywny. Po1 działa.
[t0 + 35] Link do portu Te1 / 1/14 powrócił do pracy i sprawdził, czy port z powrotem w kanale ether Po1

W naszych testach monitorowaliśmy kanał ethernetowy ruchu Po1 do kaktusów (wykres poniżej) i zauważyliśmy znaczącą zmianę wartości przepływu, kiedy wyłączyliśmy łącze te1 / 1/14 (zasoby te2 / 1/14 łącza) raczej stabilne podczas rewersu . Sprawdziliśmy też liczniki na int Po1 i były one dość stabilne.

Dwa interfejsy 10G są dołączone do kanałów Etherchann ze skonfigurowanym LACP. Wewnątrz kanału eterowego znajdują się 2 vlany. Jeden dla ruchu Multicast, a drugi dla Internetu / Cały ruch.

Czy znasz możliwą przyczynę tego zachowania?

Aby przedłużyć komentarz ytti.

Twój interwał sondowania wydaje się bardzo mały, co 10 sekund, jeśli dobrze czytam. Jest kilka powodów, dla których możesz uzyskać ten wynik.

Strona sprzętu:

• Zły wybór liczników, jeśli używasz liczników 32-bitowych, mogą one przewijać się co ~ 3,4 sekundy, jeśli używasz interfejsu 10 g przy szybkości linii
• Aktualizacja liczników, wiele większych urządzeń aktualizuje liczniki tylko dwa lub trzy razy na minutę i nigdy nie można polegać na synchronizacji. Co 30 sekund jest tak mało, że zawracam sobie głowę odpytywaniem, a nawet wtedy zawsze chciałbym mieć co najmniej dwa punkty przed wywołaniem jakiegokolwiek alarmu lub podjęcia działania
• Może wystąpić błąd, ponieważ pakiety wysyłane do przetwarzania procesora (być może przepływ netto) można od razu policzyć w porównaniu z pakietami, które nie będą grupowane w RE (widzieli to na Juniper MX)

Strona Poller:

• Czy polling odpytuje dokładnie w danym przedziale, a jeśli nie, to wstrzykuje swój wynik do rzeczywistego czasu odpytywania (np. X bitów w sekundach yz), aby można było obliczyć rozsądną szybkość
• Co się dzieje, gdy liczniki są resetowane lub SNMP GET nie reaguje na nie, różne narzędzia reagują na nie na różne sposoby

Problem polega na tym, że próbkowanie routera i własne odpytywanie nie trafiają w tym samym momencie. Oznacza to, że pomimo tego, że interwał odpytywania jest statyczny, interwały odpytywania zawierają różną liczbę próbek, których matematyka nie bierze pod uwagę.
Weź pod uwagę, że odpytałeś t1, t2, t3, ale router nie próbował niczego w odstępach t1, t2, więc cały ruch między t1, t3 zakończył się na odpytanej wartości t2, t3. Powodując, że twoja stawka wynosi 0 dla t1, t2 i ponad liniowej w t2, t3

Teraz zasugeruję jedno rozwiązanie, ale proszę zweryfikuj to z kimś, kto ma pobieżne zrozumienie matematyki.

Najpierw wymyśl interfejs, który Cię interesuje (jeśli ge-1/1/1):

snmpbulkwalk PRZEŁĄCZNIK ifDescr | grep ge-1/1/1

Wtedy zobaczysz jego numer ifIndex, załóżmy, że to „42”.

Następnie zrób coś takiego:

while true; do
  snmpbulkwalk SWITCH ifHCInOctets.42 >> DATA
  date >> DATA
  sleep 1
done

Teraz przeanalizuj wyniki, aby określić, jak często liczniki są faktycznie aktualizowane. (W razie potrzeby mogę utworzyć skrypt do analizy)

Potem przychodzi moment, w którym potrzebowalibyśmy matematyki, ale zasugeruję jedno naiwne rozwiązanie.

Jeśli interwał aktualizacji wynosi 10 s, odpytuj pole co 5 s, tj. Dwa razy częściej niż jest aktualizowane. Wtedy twoje próbki byłyby

t0, t5, t10, t15, t20, t25, t30

To byłyby twoje surowe dane, których nie używałbyś, ale wolisz odzyskać z nich rzeczywiste próbki w ten sposób

s1 = (t0+t5+t10)/3
s2 = (t10+t15+t20)/3
s3 = (t20+t25+t30)/3

Uzasadnieniem jest to, że chcemy przeciekać granice, aby zmniejszyć efekt niedokładnych interwałów odpytywania na przełączniku.

Następnie wykreślisz s1, s2, s3 i powinieneś uzyskać znacznie bardziej płynny / dokładny wynik niż to, co teraz widzisz.

Jestem jednak pewien, że nie jest to nowy problem i jestem pewien, że istnieje formalne rozwiązanie, w jaki sposób odzyskać optymalną dokładność, niestety opracowanie tego rozwiązania jest poza moim zestawem umiejętności. Coś z matematyki. Wymiany ludzi byłoby lepiej przygotowane do rozwiązania.

Ponieważ sondujesz w tym samym tempie, co liczniki są aktualizowane, prawdopodobnie nie masz synchronizacji.

Poprzez konfigurację

snmp-server hc poll <<hundredths of a second>>

możesz skrócić czas aktualizacji liczników SNMP do około 1 sekundy. Powinno to zapewnić dokładniejszą wartość przepustowości podczas odpytywania co 10 sekund.

Do twojej wiadomości, to jest ukryte polecenie.