Giants en input errors op Cisco CBS220

[boyd86]

Hallo,
Tijdens wat configuratie werkzaamheden op mijn switch (Cisco CBS220-16P) kwam ik "toevallig" een hoog aantal input errors en giants tegen, die rap opliep.
Zie:

code:

GigabitEthernet15 is up
  Hardware is Gigabit Ethernet
  Auto-duplex, Auto-speed, media type is Copper
  flow-control is auto
  back-pressure is enabled
     12451645 packets input, 13084152062 bytes, 0 throttles
     Received 256 broadcasts (29 multicasts)
     0 runts, 976842 giants, 0 throttles
     976842 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     29 multicast, 0 pause input
     0 input packets with dribble condition detected
     12147889 packets output, 12537303846 bytes, 0 underrun
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 PAUSE output

Config van de interface:

code:

 interface gi15
 switchport mode trunk
 switchport trunk allowed vlan remove 1,140
 spanning-tree portfast
 spanning-tree link-type shared
 flowcontrol auto
 description "FW"
 power inline never
!

Dit is de interface die naar mijn pfSense machine gaat, een enkele kabel met aan pfSense zijde een gigabit NIC waarop ik gebruik maak van VLAN assignments.
MTU grootte kan ik op de switch zelf niet instellen of inzien per interface, alleen globaal jumbo frames aanzetten.
Ik heb al geprobeerd om de speed en duplex handmatig te zetten op 1000/Full, maar dat helpt niks. Alleen de MTU op pfSense naar 1496 zetten lijkt het fors te verminderen maar niet weg te nemen.
Echter betekent dat volgens mij dat ik dan eigenlijk ook de MTU op alle andere apparaten moet aanpassen, en dat is niet overal mogelijk (Omada access points hebben daar v.z.i.w. geen instelling voor via de controller)
Ik vraag me af hoe ik dit het beste kan oplossen/wegnemen?
We hebben niet per se last van een traag netwerk en/of internet, maar zulke hoge en snel oplopende aantal errors lijkt me ook niet bepaald gewenst.

[JackBol]

boyd86 schreef op dinsdag 25 maart 2025 @ 17:12:
Hallo,
Tijdens wat configuratie werkzaamheden op mijn switch (Cisco CBS220-16P) kwam ik "toevallig" een hoog aantal input errors en giants tegen, die rap opliep.
Zie:

code:

GigabitEthernet15 is up
  Hardware is Gigabit Ethernet
  Auto-duplex, Auto-speed, media type is Copper
  flow-control is auto
  back-pressure is enabled
     12451645 packets input, 13084152062 bytes, 0 throttles
     Received 256 broadcasts (29 multicasts)
     0 runts, 976842 giants, 0 throttles
     976842 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     29 multicast, 0 pause input
     0 input packets with dribble condition detected
     12147889 packets output, 12537303846 bytes, 0 underrun
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 PAUSE output

Config van de interface:

code:

 interface gi15
 switchport mode trunk
 switchport trunk allowed vlan remove 1,140
 spanning-tree portfast
 spanning-tree link-type shared
 flowcontrol auto
 description "FW"
 power inline never
!

Dit is de interface die naar mijn pfSense machine gaat, een enkele kabel met aan pfSense zijde een gigabit NIC waarop ik gebruik maak van VLAN assignments.
MTU grootte kan ik op de switch zelf niet instellen of inzien per interface, alleen globaal jumbo frames aanzetten.
Ik heb al geprobeerd om de speed en duplex handmatig te zetten op 1000/Full, maar dat helpt niks. Alleen de MTU op pfSense naar 1496 zetten lijkt het fors te verminderen maar niet weg te nemen.
Echter betekent dat volgens mij dat ik dan eigenlijk ook de MTU op alle andere apparaten moet aanpassen, en dat is niet overal mogelijk (Omada access points hebben daar v.z.i.w. geen instelling voor via de controller)
Ik vraag me af hoe ik dit het beste kan oplossen/wegnemen?
We hebben niet per se last van een traag netwerk en/of internet, maar zulke hoge en snel oplopende aantal errors lijkt me ook niet bepaald gewenst.

Heb je ergens een firewall regel waar je alle ICMP dropt?

[boyd86]

Ik sta geen ICMP toe tussen VLAN’s onderling, dat klopt.
Op andere interfaces zie ik ook oplopende giants en input errors, maar niet in zulke grote getallen als naar de firewall.

[ Voor 52% gewijzigd door boyd86 op 25-03-2025 17:42 ]

[Kabouterplop01]

Heb je op de switchport je encapsulation nog ergens moeten zetten?
á la switchport encapsulation .1q ?

[JackBol]

boyd86 schreef op dinsdag 25 maart 2025 @ 17:20:
Ik sta geen ICMP toe tussen VLAN’s onderling, dat klopt.

Dan heb je PMTUD kapot gemaakt. Ik zou je aanraden om minimaal ICMP type 3 code 4 toe te staan zodat devices kunnen uitvogelen wat de maximale MTU/MSS end-to-end is.

[boyd86]

Kabouterplop01 schreef op dinsdag 25 maart 2025 @ 17:42:
Heb je op de switchport je encapsulation nog ergens moeten zetten?
á la switchport encapsulation .1q ?

Dit is op de CBS lijn van Cisco voor zover ik weet niet mogelijk/nodig. Met “switchport mode trunk” werkt het.

JackBol schreef op dinsdag 25 maart 2025 @ 17:44:
[...]


Dan heb je PMTUD kapot gemaakt. Ik zou je aanraden om minimaal ICMP type 3 code 4 toe te staan zodat devices kunnen uitvogelen wat de maximale MTU/MSS end-to-end is.

Ah, ik wist niet dat dat er achter kon zitten, kwam er via zoekacties ook niet op.
Is source en destination RFC1918 voldoende of moet ik any any gebruiken?

[ Voor 39% gewijzigd door boyd86 op 25-03-2025 17:48 ]

[JackBol]

boyd86 schreef op dinsdag 25 maart 2025 @ 17:47:
[...]

Dit is op de CBS lijn van Cisco voor zover ik weet niet mogelijk/nodig. Met “switchport mode trunk” werkt het.

[...]

Ah, ik wist niet dat dat er achter kon zitten, kwam er via zoekacties ook niet op.
Is source en destination RFC1918 voldoende of moet ik any any gebruiken?

In ieder geval de IP adressen die met elkaar praten.

[boyd86]

Het lijkt erop dat het veroorzaakt werd door mijn server waar Ubuntu Server met Docker op draait.
In pfSense had ik een floating rule any-any voor alle interfaces toegevoegd en ICMP unreach toegestaan, dat leek volgens een forumpost de juiste code te zijn.
Echter kreeg ik ook na een herstart van m’n server nog geen hits op de rule en bleek het gedrag onveranderd.
Ik heb op de NIC van de server untagged het management VLAN en subinterfaces die Docker heeft aangemaakt tijdens maken van de ipvlan's.
Als ik met "ip addr" op de Ubuntu shell keek, stonden alle MTU waardes op 1500.
Nu ik dat voor de parent interface (die dhcpv4 client is) via pfSense met DHCP optie 26 op MTU 1496 heb gezet lijkt het over, en is het aantal giants op de firewall interface beter:

code:

GigabitEthernet15 is up
  Hardware is Gigabit Ethernet
  Auto-duplex, Auto-speed, media type is Copper
  flow-control is auto
  back-pressure is enabled
     3166947 packets input, 3410720755 bytes, 0 throttles
     Received 1 broadcasts (0 multicasts)
     0 runts, 180 giants, 0 throttles
     180 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 multicast, 0 pause input
     0 input packets with dribble condition detected
     3165167 packets output, 3406001687 bytes, 0 underrun
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 PAUSE output

De server interfaces zoals ze nu weergegeven worden:

code:

eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1496 qdisc fq_codel state UP group default qlen 1000
    link/ether <weggehaald> brd <weggehaald>ff:ff:ff:ff:ff:ff
    altname enp0s31f6
    inet <weggehaald> metric 100 brd <weggehaald> scope global dynamic eno1
       valid_lft 6102sec preferred_lft 6102sec
    inet6 <weggehaald> scope link
       valid_lft forever preferred_lft forever
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether <weggehaald> brd ff:ff:ff:ff:ff:ff
    inet <weggehaald> brd <weggehaald> scope global docker0
       valid_lft forever preferred_lft forever
    inet6 <weggehaald> scope link
       valid_lft forever preferred_lft forever
5: eno1.58@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1496 qdisc noqueue state UP group default
    link/ether <weggehaald> brd ff:ff:ff:ff:ff:ff
    inet6 <weggehaald> scope link
       valid_lft forever preferred_lft forever
6: eno1.600@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1496 qdisc noqueue state UP group default
    link/ether <weggehaald> brd ff:ff:ff:ff:ff:ff
    inet6 <weggehaald> scope link
       valid_lft forever preferred_lft forever
7: eno1.19@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1496 qdisc noqueue state UP group default
    link/ether <weggehaald> brd ff:ff:ff:ff:ff:ff
    inet6 <weggehaald> scope global temporary dynamic
       valid_lft 1715sec preferred_lft 1715sec
    inet6 <weggehaald> scope global dynamic mngtmpaddr
       valid_lft 1715sec preferred_lft 1715sec
    inet6 <weggehaald> scope link
       valid_lft forever preferred_lft forever
8: eno1.78@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1496 qdisc noqueue state UP group default
    link/ether <weggehaald> brd ff:ff:ff:ff:ff:ff
    inet6 <weggehaald> scope link
       valid_lft forever preferred_lft forever
10: vetha1aac50@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether <weggehaald> brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 <weggehaald> scope link
       valid_lft forever preferred_lft forever

Enigste waar ik nog een beetje over twijfel of die 1496 MTU goed is/verstandig is, en op welke plek ik die moet instellen. Wat ik uit de Docker documentatie begrijp ondersteund ipvlan geen mtu optie in de configuratie.

[ Voor 49% gewijzigd door boyd86 op 26-03-2025 07:33 ]

[Kabouterplop01]

Dat is dan toch apart als je geen hits krijgt op je acl, dan moet het iets anders zijn.
(Wel goed dat het met het aanpassen van de MTU in dhcp option het patroon beïnvloedt, ljikt daar mee van doen.)
Enige manier die ik me kan bedenken is capturen, maar waar zou je dan beginnen?
Iets met een icmp debug en een packet/frame size onderzoek. (voor en na de switchport)

edit: zoals ik begrijp uit de documentatie van docker zou het opstarten van docker met een mtu die hoger licht dan de mtu van de hoofdinterface voor zoiets als Giants kunnen zorgen, die frames zijn immers te groot voor de mtu size

[ Voor 24% gewijzigd door Kabouterplop01 op 27-03-2025 09:57 ]

[boyd86]

Intussen heeft pfSense wel enkele states gehad op de rule. Ik ga de logging voor die rule nog even aanzetten om te kijken wat er voorbij komt. Wat ik nu op m’n switch nog zie qua giants en input errors is vooral afkomstig van mijn WiFi access points van Omada (2x EAP615-Wall en 2x EAP653 met OC200 controller).
Die kan ik echt nog niet verklaren, nergens een optie voor MTU gevonden in Omada.
Wat ik nog uit wil sluiten is of de giants daadwerkelijk gedropt worden of dat de log counter puur informatief is.
Standaard MTU grootte zou toch gewoon moeten werken met alleen 802.1q tags zonder verdere poespas als QinQ of PPPoE?
Als iemand nog tips heeft in de juiste richting houd ik me aanbevolen .
Sowieso laat ik weten als ik een oplossing heb gevonden!

[Kabouterplop01]

Giants worden gedropped tenzij er wordt gefragmenteerd, maar dat gebeurt op laag 3 en aangezien je het over rfc1918 adressen hebt, ook al zitten er vlan tags aan vast, geloof ik niet dat je routeert tussen vlans, bovendien zouden die tags er af moeten worden gesloopt door je ROAST (je pfsense).
Daar zitten je laag 3 boundaries van de vlans, de vlan interfaces met de ip adressen, toch?
Wat ik me dus afvraag is of die Cisco ISL tags gebruikt ipv .1q en dat je pfsense daar iets van vindt.
Die giants en de input errors zijn in aantal evenredig denk ik.
Overigens volgens mij is als je giants hebt en het verkeer wordt getransporteerd moet je ook runts hebben, dat is het omgekeerde, frames die te klein zijn voor de minimum frame size. Daarom denk ik dat het gedropped wordt. er zijn in je interface stats nl geen runts te zien.
Maar misschien is het nog wel veel complexer en is het applicatief. (dus niet op laag 2 of 3)
Wat @JackBol meldde was echt een eye opener, had ik nog nooit van gehoord/nog niet over nagedacht. Dus dit ge-nerd (complimenten) is tof. Ben heel benieuwd.

[mash_man02]

Vroeger moest je de encapsuplatie opgeven anders geen trunk. Sinds een aantal jaren is 802.1Q standaard voor een trunk. Je kunt ook even proberen of je de MTU op de PFsense doos naar beneden kunt brengen zodat deze passend is voor de NIC.

Maar ICMP gebruiken om de juiste MTU te kunnen discoveren is uiteraard de geprefereerde methode.

[boyd86]

Edit 9:17:
Misschien toch een cosmetische bug! Ik vraag me nog wel af of er nog goede tools zijn waarmee ik kan dubbelchecken dat mijn gehele netwerk nu goed geconfigureerd is voor onder andere PMTUD en andere relevante zaken. Tips?

Edit 08:15:
Met mturoute gekeken welke PMTU ik terug krijg vanaf een WiFi verbonden laptop, dit is zowel naar externe als interne IP adressen 1500 bytes:

code:

mturoute 8.8.8.8
* ICMP Fragmentation is not permitted. *
* Speed optimization is enabled. *
* Maximum payload is 10000 bytes. *
+ ICMP payload of 1472 bytes succeeded.
- ICMP payload of 1473 bytes is too big.
Path MTU: 1500 bytes.

Originele post;
Even een update; ik heb:

• Een netwerkdiagram gemaakt voor het begrip. pfSense is inderdaad voor alle VLAN's de gateway. Switches hebben alleen een IP in management die ze via DHCP van pfSense krijgen, dus wat dat betreft duidelijke L2/L3 scheiding.
  
• Op alle switches de koppel interfaces (feitelijk alle zwarte lijntjes die in diagram staan) gewijzigd van trunk mode naar general mode, met dezelfde untagged/tagged VLAN configuratie. Alles bleef werken maar dit leek niet het probleem op te lossen, wel lijkt me dit eigenlijk beter vanwege naar het schijnt betere 802.1q compatibiliteit.
• Packet captures gemaakt op een EAP653 en EAP615, om maar eens ergens te beginnen, Docker server had ik immers al aangepast. Hier vielen drie dingen op:
• EAP lijkt te grote pakketten naar de controller te sturen (DF-bit gezet):
• MTU voor Docker toch niet laag genoeg? (DF-bit gezet) Docker server is bekabeld op de CBS220-16P aangesloten met tagged VLAN's en management untagged.
• Reolink deurbel lijkt ook een te hoge MTU te gebruiken? Bij openen van de Reolink app die dan gelijk de stream van de deurbel opent loopt het aantal Giants iig duidelijk op, kijkend op de poort van de EAP653 waar de deurbel mee verbonden is. Deurbel --> Hub heeft geen DF-bit gezet, andersom wel. Reolink hub is bekabeld aangesloten op de SG250-08.
  

Even hardop denkend; zou ik geen TCP retransmits o.i.d. moeten zien voor de pakketten waar DF-bit gezet is? Tussen de Reolink hub en de iPhone zit pfSense, en het feit dat ik dus in de packet capture van het EAP een ogenschijnlijk groter pakket voorbij zie komen vanwege oplopend aantal giants zou dan misschien toch suggereren dat de switch het puur cosmetisch logt?

Wat ik daarna nog heb geprobeerd, is
1. Op de Reolink en management DHCP scopes (waar de EAP devices en controller ook in zitten) optie 26 met waarde 1480 toegevoegd, dit heeft het niet verholpen.
2. Op de floating rule in pfSense alle ICMP types toegestaan, dit heeft het ook niet verholpen. Ik zie wel meer voorbij komen in de log, immers wordt ICMP echo ook doorgelaten. Maar ik zie niet de subnet namen voorbij komen van de nu ogenschijnlijk "problematische" segmenten.

[ Voor 37% gewijzigd door boyd86 op 28-03-2025 10:41 ]

[Kabouterplop01]

Staat toevallig Bypass firewall rules for traffic on the same interface aan?
(overigens je lijkt toch wel te routeren )

Ik kan het nog niet duiden, wat er gebeurt en hoe/waarom. Zie je iets mafs in de sequences? (daar moet je toch e.e.a overgeslagen zien worden en iddd retransmits daarop)
asymetrische paden ergens?
rraarr

[boyd86]

Thx voor je reactie, ik had het over RFC1918 adressen in de context van de firewall rule benodigd voor ICMP op tip van @JackBol. Ik heb namelijk een alias object voor RFC1918, en door die als source en destination te gebruiken heb ik automatisch alle lokale subnets in scope.
Maar goed, die rule heb ik als “any-any” aangemaakt.
Routering tussen de VLAN’s gebeurt inderdaad op pfSense, hij heeft geen invloed op verkeer binnen een VLAN.
Zoals ik aangegeven had in m’n bovenste edit van vorige post lijkt het er sterk op dat het een cosmetische bug in de CBS switches is.
Retransmits en TCP streams die uit de pas lopen lijken niet aan de orde.
Ik ben nu eigenlijk nog op zoek naar tips voor een tool die alle belangrijke aspecten automagisch door kan lichten, om evt optimalisatie te kunnen doorvoeren of andere fouten eruit te halen.

[Jan-man]

Zet eens spanning tree protocol helemaal uit op de CBS! Hebben in verleden wel eens problemen gehad die nergens op sloegen en opgelost waren naar spanning tree uit te zetten.

Wat betreft MTU wel een beetje oppassen . Vooral Microsoft diensten kunnen spontaan onbereikbaar worden met de verkeerde MTU waarde. Zo had ik een tijd terug bij een verhuizing van een klant dat Microsoft diensten in het nieuwe pand steeds wegvielen of niet werkte. Bleek dat de router in het oude pand een aangepaste fixed MTU waarde had op hun lijn van 1496, wat daar wel goed werkte en de verbinding in het nieuwe pand 1500 (default waarde) had. Resultaat was dat internet prima werkte maar alles met Microsoft niet.... Heeft wat uurtjes gekost om dat te vinden, eenmaal omgezet naar 1500 was het probleem direct weg.

[boyd86]

Spanning tree is global disabled, en RSTP ook.
Ik ervaar verder geen performance issues, af en toe wat brakke WiFi performance maar dat is omdat ik voor de beneden verdieping nog aan het tweaken ben met zendvermogen.
De positieve bijdrage van ICMP in een gesegmenteerd netwerk was voor mij ook een eyeopener, en ben dus vanwege die reden ook benieuwd naar jullie ervaringen met tools die goed kunnen duiden of de basisprincipes in het netwerk goed staan.
Dat vermoeden heb ik wel, maar meten…

[Kabouterplop01]

Ik ken wel zo'n tool die op basis van regex kijkt naar config files.
vreselijk kostbaar; het heette Skybox en is onlangs overgenomen door Tufin.
Het kan je config files parsen op security bcp's (config volgens bijv NIST, of CIS) maar ook op simpele configuratie zaken.
maar je kunt dat uiteraard ook met een fileserver regelen met wat scripts die dat checken.
Het is een soort quality assurance tool

[boyd86]

Dat is meer passief checken lijkt het. Ik doel op een actieve controle a la iperf3 en dat soort checks. Ik ben intussen TP-Link WiFi navi tegengekomen en die is vrij goed in meerdere controles vanaf 1 plek, vooral de roaming test werkt verrassend handig. Echt feitelijke controles voor PMTU en andere soort auto-discovery achtige protocollen checkt ie alleen niet.