ostatnio podczas przeglądania logów na kontrolerze WLAN, zauważyłem, że od czasu do czasu nie widać odpowiedzi do stacji z serwera DHCP. trochę się zdziwiłem, bo domownicy nie narzekają - a narzekaliby od razu. postanowiłem sprawę sprawdzić po kolei na wszystkich elementach sieci.
pierwsze podejrzenie padło na przełączniki. dlaczego? skoro generalnie wszystko działa, nikt nie narzeka (a narzekają bardzo szybko) prawdopodobnie chodzi o dropy na interfejsach. komunikaty wskazywały bowiem na bardzo rzadkie występowanie problemu. konfiguracja QoS na przełącznikach Cisco Catalyst i Nexus nie jest prosta - to trzeba sobie powiedzieć od razu. w porównaniu jednak do sprzętu innych producentów… właściwie nie ma co porównywać. da się tu z jednej strony zrobić wszystko, z drugiej strony ktoś nieostrożny może sobie strzelić w głowę na tyle wymyślnych sposobów, że jeśli nie spędziłeś z QoSem tygodni na labowaniu - załóż, że lepiej po prostu nic nie rekonfigurować. wykorzystaj zatem albo dedykowane GUI pozwalające między innymi sprawnie wdrożyć politykę QoS na całej sieci - Cisco DNA Center, albo ogranicz się do dwóch podstawowych stanów - QoS włączony (mls qos) albo wyłączony no mls qos. zanim cokolwiek zaczniesz robić, rozważ sprawdzenie tych dwóch najprostszych stanów.
nie od tego jednak jestem podwójnym CCIE, żeby się bać takich sytuacji. tym niemniej, konfiguracja wykonana już dawno temu, odpowiednio mapująca klasy ruchu do kolejek i gwarantująca odpowiednie gwarancie i podział buforów ewidentnie działała - zero dropow na wszystkich portach.
zajrzałem zatem do wspomnianych wcześniej na blogu serwerów DHCP. i oto - coś dziwnego, czego nie widziałem wcześniej (bo nie szukałem). w logach serwera DHCP na poziomie debug (domyślnie na FreeBSD lądują w /var/log/debug.log), znalazły się dosyć często takie wpisy:
Aug 20 06:32:37 ns1 dhcpd[6775]: 3 bad udp checksums in 5 packets
Aug 20 07:01:23 ns1 dhcpd[6775]: reuse_lease: lease age 1802 (secs) under 25% threshold, [...]
Aug 20 07:31:25 ns1 dhcpd[6775]: 3 bad udp checksums in 5 packets
Aug 20 07:31:31 ns1 dhcpd[6775]: reuse_lease: lease age 3610 (secs) under 25% threshold, [...]
Aug 20 07:32:42 ns1 dhcpd[6775]: reuse_lease: lease age 3605 (secs) under 25% threshold, [...]
Aug 20 07:33:55 ns1 dhcpd[6775]: reuse_lease: lease age 4888 (secs) under 25% threshold, [...]
Aug 20 07:38:22 ns1 dhcpd[6775]: reuse_lease: lease age 3610 (secs) under 25% threshold, [...]
Aug 20 07:39:11 ns1 dhcpd[6775]: 3 bad udp checksums in 5 packets
Aug 20 08:01:32 ns1 dhcpd[6775]: reuse_lease: lease age 5411 (secs) under 25% threshold, [...]
Aug 20 08:02:45 ns1 dhcpd[6775]: reuse_lease: lease age 5408 (secs) under 25% threshold, [...]
Aug 20 08:02:45 ns1 dhcpd[6775]: 3 bad udp checksums in 5 packets
nie wygląda to dobrze. skąd błędy? nie po to zmieniałem wirtulną kartę sieciową pod VMware ESXi z emulowanego Intela (em), o którym wiadomo, że występują różne problemy na natywnego vmx, żeby teraz cierpieć. szukanie w internecie nie dało nic sensownego, oprócz starych wpisów z 2011 i 2012 gdy programiści starej wersji Ubuntu walczyli z ISC o załatanie problemów w stosie virtio pod KVM.
tu mi zaświtało. czasem kombinacja stosu sieciowego systemu operacyjnego oraz hypervisora powoduje problem z akceleracją na sprzętowej karcie sieciowej.
zatem szybki test na sieciówce serwera:
[ns1 ~]$ ifconfig vmx0
vmx0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=e403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
ether 00:0c:29:77:12:47
[...]
bingo - RXCSUM,TXCSUM,TSO4,TSO6,RXCSUM_IPV6,TXCSUM_IPV6. a zatem szybko:
# ifconfig vmx0 -tso4 -tso6 -rxcsum -txcsum -rxcsum6 -txcsum6
…i jest lepiej. żadnych komunikatów o błędach w sumie kontrolnej pakietów UDP którymi zajmuje się serwer DHCP i logi z kontrolera WLAN również pokazują brak problemów z pozyskiwaniem adresów przez DHCP.
dla testu spróbowałem przetestować włączenie tych opcji po stronie hypervisora - niestety to nie dało rezultatu. zatem, przynajmniej na razie - nawet używając sterownika vmx pod FreeBSD pracującym na VMware ESXi (6.5/6.7) trzeba akcelerację na poziomie systemu operacyjnego (i hypervisora) wyłączyć.
czasami najprostsze rzeczy potrafią zaskoczyć - a dobry inżynier sieciowy powinien być w stanie prześledzić cały stos i znaleźć problem.