Napatech capture-SmartNICs: wat gebeurt er nu echt met een SFP+ die niet op de qualified list staat
We draaien packet capture op een handvol Napatech-kaarten en ik ben de optiekbestelling voor het volgende rack aan het samenstellen. Voordat ik iets uitgeef wil ik begrijpen wat de qualified module-lijst in de praktijk daadwerkelijk betekent, want de formulering laat ruimte voor interpretatie.
- Napatech NT40E3 en NT20E3 capture-kaarten in de bestaande hosts
- Een NT200A02 die in de nieuwe build komt
- Vooral 10G SFP+- en 25G SFP28-links, wat 40G QSFP+ richting de aggregatielaag
- Een plank Coherent FTLX8571D3BCL 10G SFP+-modules die al op voorraad ligt
Wat er op de testbank ligt:
NT40E3, NT20E3, NT200A02 - capture cards
FTLX8571D3BCL - 10G SR/LR SFP+ from stockTot nu toe heb ik de qualified module-directory doorgenomen, een paar onderdelen tegen onze kaarten gelegd en voor elk naar de driverversiekolom gekeken. Wat ik nog steeds niet kan doorgronden is het faalgedrag. Als ik een mechanisch identieke SFP+ die niet op die lijst staat in een NT40E3 zet, weigert de kaart hem dan zoals een switch met een EEPROM-check zou doen, of blijft hij gewoon donker liggen? En omgekeerd: garandeert het feit dat iets op de lijst staat daadwerkelijk dat de module wordt aangestuurd?
Comments 3
Geen EEPROM-lock op Napatech, dus dat switch-achtige weigeringsscenario kun je laten vallen. Wij draaien al jaren NT20E3's en een NT40E3, en nog nooit heeft een kaart een module uitgespuugd vanwege een vendorcode.
Wat er wel is, is een directory van qualified pluggables, en die is smaller dan mensen verwachten. Drie dingen per item: welke module, tegen welke SmartNIC hij getest is, en de vroegste driverrelease die hem ondersteunt. Dat derde punt heeft mij ooit te grazen genomen - een onderdeel kan voor jouw exacte kaart vermeld staan en onder een oudere driver nog steeds niets doen. Er is ook een regulatory-safety-kolom, en die leest niet voor elk item hetzelfde. Jouw FTLX8571D3BCL duikt overal in die lijst op als qualified 10G SR/LR-onderdeel, dus de voorraad op de plank is een veilig startpunt.
Het probleem waar je naar vraagt zit in de lijst zelf ingebakken. Vermeld staan is niet hetzelfde als aangestuurd worden: of een moduletype werkt hangt af van het firmware-image - wat Napatech meelevert in een turnkey-kaart, of wat je zelf bouwt op een Link-Programmable exemplaar. Dus een mechanisch prima SFP+, vermeld of niet, kan donker blijven liggen omdat het image hem nooit heeft leren kennen, niet omdat iets hem geweigerd heeft. Voor de turnkey-kaarten beslissen de datasheets, niet de directory.
Dat is precies het stuk dat ik verkeerd had. Ik las de directory als een whitelist die de kaart afdwingt, terwijl het dichter bij een verklaring ligt van wat de firmware geleerd is aan te sturen. Twee van onze hosts zijn turnkey en de nieuwe NT200A02 komt erbij als Link-Programmable, dus dat zijn twee verschillende vragen en zo ga ik ze ook behandelen: datasheets voor het turnkey-paar, ons eigen image voor de programmeerbare kaart. De FTLX8571D3BCL-voorraad dekt de 10G-kant, en ik check de driverversiekolom voordat ik iets vastleg voor de 25G-links.
Het is de moeite waard om te weten hoe verschillend leveranciers dit verwoorden, want het praktische gevolg is niet in elk geval hetzelfde.
Extreme, dat nu de Brocade SLX-, VDX- en MLX-lijnen naast zijn eigen platforms bezit, houdt een approved list per productfamilie aan. De bijbehorende beleidsnotitie is bot: sluit iets niet-goedgekeurds aan, optiek of de bijbehorende interfacemodules, en de gevolgen zijn voor jou alleen - ze beloven geen garantie, geven geen compliance-verklaring af en nemen geen serviceverplichting op zich. Onderdelen die op de lijst staan dragen certificering voor NRTL, FCC CFR 21 1040.10, CDRH, CE, EN60825-1 en/of GR-468. Wat het je niet vertelt, is hoe een gegeven doos zich gedraagt zodra je iets niet-vermelds insteekt.
Barracuda doet het andersom en houdt helemaal geen appliance-whitelist aan, en leunt op de Intel-driver-testlijst, omdat de acceptatie door de NIC wordt bepaald: een ET076-module is 4x 10GbE SFP+ op een Intel X710, dus wat de X710-driver weigert, weigert de firewall ook. Cisco blokkeert op de Firepower 2100 helemaal geen niet-Cisco SFP's, het raadt ze alleen af, en TAC kan een interoperabiliteitscase met zo'n module afwijzen. Drie beleidslijnen, drie behoorlijk verschillende faalmodi.