SNMP

Tento článek popisuje základní konfiguraci OLT přes SNMP. Popis má podobu spouštění známých nástrojů balíku Net-SNMP, které jsou součástí běžných linuxových distribucí - např. snmpget a pod. V popisu také využíváme shell, konkrétně GNU Bash.

Symbol $OPTS přestavuje společné/základní parametry nástrojů Net-SNMP:

• cestu k souborům MIB, například -M ${0%/*}/mibs (podsložka mibs) - pro naše příklady potřebujete příslušné MIB Huawei,
• zákaz lokální kontroly indexů -Ir (nutné pro SmartAX - vizte upozornění na konci sekce ifIndex).

Symbol $AGENT pak obsahuje parametry pro komunikaci s konkrétním agentem (s konkrétním OLT):

• nastavení verze SNMP a autorizace, například -v 3 -a SHA -x AES -l authPriv -u admin -A authpass -X privpass (odpovídá příkladu nastavení OLT v části SNMP verze 3),
• adresu/název OLT, například 10.20.30.40.

Příklad našeho zápisu:

OPTS="-M ${0%/*}/mibs -Ir"
AGENT="
    -v 3 -a SHA -x AES -l authPriv
    -u admin -A authpass -X privpass
    10.20.30.40
"
 
snmpget $OPTS -m HUAWEI-MIB $AGENT \ # v HUAWEI-MIB jsou definovány hodnoty 'sysObjectID' pro zařízení Huawei
    SNMPv2-MIB::sysObjectID.0

V první části definujeme symboly $OPTS a $AGENT (ty v příkladech níže už znovu nedefinujeme). Druhá část pak obsahuje volání nástroje snmpget: je rozepsané kvůli přehlednosti na dva řádky (které jsou spojeny zpětným lomítkem - \) a první řádek také obsahuje komentář (#). Ve skutečnosti jde o jediný příkaz.

Pokud máte vše nastaveno správně, mělo by OLT na výše uvedený příkaz snmpget odpovědět ve stylu:

SNMPv2-MIB::sysObjectID.0 = OID: HUAWEI-MIB::ma5680

Kromě symbolů $OPTS a $AGENT budeme v popisu používat ještě $IFIDX pro ifIndex; $F, $S a $P pro číslo vany (frame, zde vždy 0), slotu a portu; a $ONT pro ONT ID (index ONT v rámci portu GPON).

Pokud popisujeme vytvoření řádku v konceptuální tabulce, uvádíme nejprve povinné sloupce a za nimi hned sloupec RowStatus. Pak teprve následují další sloupce (nepovinné nebo jinak závislé).

Tato část popisuje specifické chování SNMP agenta v zařízeních SmartAX.

Pokud chceme spravovat OLT zabezpečeným a/nebo autorizovaným způsobem (SNMP verze 3), musíme vytvořit příslušný účet USM, nejlépe s právy na celou MIB (view iso):

snmp-agent sys-info version v3
# můžeme povolit třeba i 'v2c' a nastavit community pro (nezabezpečené) čtení statistik, tj.
#     snmp-agent sys-info version v2c v3
#     snmp-agent community read statistiky
snmp-agent mib-view view_iso include iso
snmp-agent group v3 group_admin privacy read-view view_iso write-view view_iso
# uživatel se jménem 'admin', heslem/klíčem pro autorizaci 'authpass' a pro šifrování 'privpass'
snmp-agent usm-user v3 admin group_admin authentication-mode sha authpass privacy-mode aes128 privpass

SmartAX při chybě neidentifikuje v odpovědi (Response-PDU) konkrétní proměnnou (varbind), která chybu způsobila: pole error-index posílá při chybě vždy s hodnotou 1. Přesnější určení chyby lze vyčíst aspoň z pole error-status: tam kromě standardních hodnot (0 až 18) používá i „proprietární“ čísla chyb (cca. sedmimístná čísla, později sem přidáme tabulku některých důležitých proprietárních chyb).

Bohužel nástroje Net-SNMP, které používáme v tomto článku, tato proprietární čísla chyb nezobrazují. Místo toho vypisují jen Reason: Unknown Error (a k tomu následuje Failed object: a zavádějící výpis první proměnné - protože error-index je u proprietárních chyb SmartAX vždy 1). Toto chování by šlo změnit jedině úpravou zdrojových kódů Net-SNMP: funkce snmp_errstring() v souboru snmplib/snmp_client.c.

Pokud PDU (hlavně paket set-request) obsahuje více nesouvisejících proměnných (varbinds) a některá z nich způsobí chybu, tak jsme vypozorovali, že se proměnné zpracovávají postupně a ty, které předcházely chybě, se aplikují. Zápis (set-request) proměnné s neexistujícím OID nemusí způsobit chybu: OLT odpoví, jako by zápis provedlo, a neexistenci OID lze detekovat jedině čtením (get-request).

Konfigurační parametry jsou často v MIB vyjádřeny pomocí tabulek. SmartAX implementuje konceptuální tabulky (conceptual table) podle SMIv2: každá tabulka obsahuje sloupec typu RowStatus.

Vytváření nových konceptuálních řádků funguje jen v režimu createAndGo: připravíme si index nového řádku (to záleží na povaze tabulky) a v jednom PDU (v jednom paketu set-request) pošleme všechny povinné sloupce tabulky a mezi nimi kdekoliv i sloupec typu RowStatus s hodnotou createAndGo(4).

Řádek se odstraní zápisem hodnoty destroy(6) do sloupce RowStatus.

PDU, ve kterém vytváříme řádek, nesmí obsahovat nic jiného, než sloupce tohoto řádku: pokud se pokusíme vytvořit dva řádky v jediném PDU, vytvoří se jen první a operace pak skončí s chybou. Pokud se pokusíme spolu s vytvořením řádku ještě třeba jen změnit nebo vymazat jiné řádky, tak to také zafunguje chybně: operace se provedou, jako by všechny proměnné (varbind) měly index toho vytvářeného řádku.

Vše ostatní lze kombinovat: v rámci jednoho PDU lze třeba změnit několik řádek a zároveň některé řádky smazat.

Jednotlivé hodnoty ve sloupci konceptuální tabulky se v SNMP rozlišují pomocí indexu. Ten se přenáší v PDU jako (koncová) část OID. Přitom index může mít i několik složek a některé mohou mít i proměnnou délku (indexem může být třeba i OCTET STRING), proto je v RFC 2578, sekci 7.7 definováno, jak se z těchto složek poskládá OID. Pokud má složka proměnnou délku, vloží se do OID nejprve tato délka a pak teprve data složky. Pokud má i poslední (tj. i jediná) složka proměnnou délku, může se taková složka v MIB deklarovat s příznakem IMPLICIT a pak se do OID délka nevkládá - příjemce ji odvodí z celkové délky OID.

Originální Huawei MIB ale obsahuje příznak IMPLICIT i v místech, kde to není možné. Například HUAWEI-XPON-MIB::hwGponDeviceLineProfTcontCfgEntry má dvousložkový index: první složka (hwGponDeviceLineProfTcontCfgLineProfNameIndex) obsahuje jméno profilu, je typu OCTET STRING (tj. proměnná délka), druhá složka (hwGponDeviceLineProfTcontCfgTcontIndex) obsahuje číslo T-CONT a je typu Integer32 (tj. pevná délka). MIB chybně označuje obě složky příznakem IMPLICIT, přitom tento příznak nesmí mít ani jedna z těchto složek: jméno profilu není poslední složkou a T-CONT nemá proměnnou délku. Ve skutečnosti OLT mapuje OID tak, jako by zde příznaky IMPLICIT nebyly: před jméno profilu přidá délku a T-CONT pošle samozřejmě bez délky.

Nástroje z balíku Net-SNMP tyto nadbytečně příznaky IMPLICIT ale vyhodnotí a chovají se pak chybně. Například pro sloupec hwGponDeviceLineProfTcontCfgRowStatus a index odpovídající profilu s názvem „mdu“ a T-CONTu číslo 2 vypíše snmpwalk toto:

$ snmpwalk ... HUAWEI-XPON-MIB::hwGponDeviceLineProfTcontCfgRowStatus
# profil nesmyslně '.mdu.' a T-CONT chybí úplně
HUAWEI-XPON-MIB::hwGponDeviceLineProfTcontCfgRowStatus.'.mdu.' = INTEGER: active(1) 
# takto by to mělo vypadat
HUAWEI-XPON-MIB::hwGponDeviceLineProfTcontCfgRowStatus.'mdu'.2 = INTEGER: active(1) 

OLT pošle OID hwGponDeviceLineProfTcontCfgRowStatus.3.109.100.117.2 (3 je délka, 109/100/117 jsou ASCII kódy mdu, 2 je číslo T-CONT) - lze zjistit pomocí snmpwalk -On - ale Net-SNMP to vyhodnotí jako .mib. (ty tečky patrně vyjadřují „netisknutelné“ znaky s ASCII kódem 3 a 2).

Jak to vyřešit? Vypozorovali jsme (pouze namátkou z několika konceptuálních tabulek), že OLT použije implicitní délku proměnné složky jen tam, kde je to povoleno dle RFC (a kde je to zároveň definováno v MIB). V originálních MIB je proto potřeba ignorovat slovo IMPLICIT všude tam (a jen tam), kde podle RFC nesmí být.

Komunikaci s agentem lze zefektivnit posíláním větších paketů. Má to smysl hlavně při vyčítání tabulek: když použijeme hromadné vyčítání (bulk request), dokáže SmartAX sestavit odpověď o velikosti až cca. 15 kB (kilobajtů) a pak ji (fragmentovanou) najednou poslat.

Je potřeba ale dát pozor na příliš vysokou hodnotu max-repetitions (-Cr v Net-SNMP). Pokud vyčítáme hodnoty pevné délky (např. Integer32), tak SmartAX zpracuje i vysoké max-repetitions: odpověď omezí na těch cca. 15 kB (ale trvá mu to skoro dvakrát déle). Když to samé zkusíme pro hodnoty proměnné délky (OCTET STRING), tak to občas zafunguje špatně a SmartAX vrátí nekompletní odpověď s chybou tooBig(1). Hodnotu max-repetitions proto volíme tak, aby se odpověď spolehlivě vešla do 15 kB: to funguje vždy a je to i rychlejší v případě hodnot pevné délky.

SmartAX nepodporuje hromadné vyčítání více než jedné proměnné! Pokud pošleme požadavek s více proměnnými (přesně řečeno: seznam proměnných - varbind list - obsahuje kromě non-repeaters ještě více než jednu proměnnou), tak se SmartAX zachová, jako kdyby seznam obsahoval jen jednu (první) proměnnou.¹⁾

Vyčítání statistických údajů je sice možné přes SNMP, jak ho dělají běžné dohledové systémy, ale doporučujeme ho jen pro čtení takových hodnot, které řídicí karta přímo zná (a nemusí je zjišťovat komunikací s ONT): například stavy OLT, čítače paketů na portech OLT a pod.

Pro údaje z ONT, jako je třeba síla přijímaného signálu na GPON portu ONT, se SNMP nehodí: OLT zjišťuje údaj až v době, kdy přijde SNMP požadavek, a tak hromadné vyčítání trvá dlouho. Navíc potřebujeme číst hodnoty z tisíců ONT - to běžně dohledové systémy přes SNMP nedělají. SmartAX má na to speciální funkcionalitu: hromadné statistiky (bulk statistics). Dokáže vnitřně periodicky sbírat vybrané údaje (včetně té síly signálu z ONT) a jednou za 15 minut (periodu lze volit, 15 minut je nejkratší možná) všechny údaje uložit do souboru. Tento soubor pak nahraje (FTP, SFTP, TFTP) na server pro další zpracování.

O hromadných statistikách napíšeme časem samostatný článek. Hromadný sběr se aktivuje pomocí SNMP (HUAWEI-BULKSTATISTICS-MIB, nelze přes CLI) a pak už dohled jen čeká na automatické uložení (když je nastaven file-server auto-backup bulk-stat), nebo dohled přijímá asynchronní oznámení (trap) o kompletaci statistik a na jeho základě pošle přes SNMP do OLT příkaz pro uložení souboru na server (tato druhá varianta je rychlejší - automatické ukládání dělá SmartAX s prodlevou cca. 18 minut).

Hromadné statistiky obsahují většinu údajů, které operátory v praxi zajímají. Přímé čtení statistických hodnot přes SNMP proto budete potřebovat hlavně v případě, že chcete konkrétní hodnoty zjišťovat častěji, než jednou za 15 minut.

Častým indexem v MIB je IF-MIB::ifIndex. SmartAX nepřiřazuje rozhraním indexy postupně od 1, jak je tomu zvykem u jednodušších zařízení, ale vytváří je složením čísel (indexů) vany (frame), slotu a portu takto:

ifIndex = (T << 25) + (F << 19) + (S << 13) + (P << psh) + C

kde:

• T identifikuje technologii portu (vizte tabulku níže),
• F je číslo vany (frame) - samostatné OLT má vždy číslo 0,
• S je číslo slotu - 0 až cca. 22 (podle typu OLT),
• P je číslo portu - 0 až cca. 47 (podle typu karty),
• psh je posun čísla portu (vizte tabulku níže),
• C je číslo kanálu (channel) - pouze u DSL; u PON je nulové,
• x « y je posun čísla x o y bitů vlevo (=x·2^y).

Tento vzorec pro ifIndex jsme vypozorovali z OLT řady MA5600. Je pravděpodobné, že novější MA5800 vytváří indexy jinak (mj. proto, že podporuje více van, a tak už nestačí 6 bitů na pole F): univerzální implementace by proto měla raději projít sloupec IF-MIB::ifName a indexy ifIndex si odvodit z něj. Aktualizace: MA5800 počítá ifIndex stejně, jako MA5600. Stejně ho počítají i MA5821 (MDU ONT), ale ta mají jiný rozdíl: v ifName uvádějí u rozhraní Ethernet o 1 menší číslo portu (tj. ifName číslují od 0, zatímco v CLI i ve výpočtu ifIndex jsou porty Ethernet v MDU číslovány od 1). Následující tabulka uvádí hodnoty T a psh a také syntaxi názvů v ifName.

Pole ifIndex je podle IF-MIB typu Integer32 (32-bitové číslo se znaménkem - signed) s rozsahem 1 až 2147483647 (= nejvyšší kladné číslo pro typ Integer32). SmartAX to ale porušuje a používá i jiné (vyšší) hodnoty. Ve vaší konkrétní implementaci SNMP musíte buď vynutit zpracování pole ifIndex jako (32-bitového) čísla bez znaménka - unsigned, nebo výše uvedené hodnoty převést na číslo se znaménkem: například číslu 4194330880 uvedenému výše odpovídá „znaménková“ hodnota -100636416.

U nástrojů Net-SNMP stačí vypnout kontrolu indexů: -Ir.

Také asynchronní oznámení (trap) zasílá SmartAX nestandardně. V režimu snmp-agent trap-format standard obsahují zprávy trap tyto vazby proměnných (varbind):

• sysUpTime - standardně,
• snmpTrapOID - zde je standardní (skutečný) OID podle definice konkrétního trap v MIB,
• HUAWEI-SNMP-NOTIFICATION-MIB::hwTrapSN, ::hwTrapLevel, ::hwSpecificTrapType - vysvětleno v HUAWEI-SNMP-NOTIFICATION-MIB,
• HUAWEI-DEVICE-MIB::hwSysIpAddr - IP adresa agenta (OLT),
• HUAWEI-SNMP-NOTIFICATION-MIB::hwTrapID - identifikátor typu: určuje typ SNMP trap, ale v dokumentaci nejsou nikde uvedeny hodnoty tohoto identifikátoru (a neshodují se s hodnotami snmpTrapOID, přestože jsou vlastně jejich obdobou),
• a nakonec následují vazby proměnných podle definice konkrétního trap v MIB.

Vazby tedy obsahují navíc 5 proměnných (hwTrapSN až hwTrapID), které nejsou uváděny v definicích trap v originálních souborech MIB.

V režimu snmp-agent trap-format private (ten je nastaven „z továrny“) je situace ještě komplikovanější: trap obsahuje stejný počet vazeb proměnných, jako v režimu standard, ale:

• snmpTrapOID - neobsahuje OID konkrétního typu trap, ale je vždy odeslán s hodnotou proměnné SNMPv2-MIB::sysObjectID, tj. například HUAWEI-MIB::ma5680,
• všechny další vazby proměnných (tj. všechny kromě prvních dvou) mají jako Object name (tj. jako OID určující typ proměnné) vyplněn opět OID ze sysObjectID, jejich hodnoty odpovídají „stejnolehlým“ hodnotám z režimu standard.

Je jasné, že (tovární/implicitní) režim private je pro běžné implementace SNMP nepoužitelný. Posílá nesmyslné OID ve vezbách proměnných a hlavně v něm nelze určit konkrétní typ oznámení (na to bychom jedině potřebovali nějaký číselník hodnot hwTrapID). Proto používáme asynchronní oznámení jedině v režimu standard:

snmp-agent trap-format standard
#snmp-agent mib-view view_iso include iso
# USM skupina ('group_traps') musí mít nastaveno `notify-view`!
snmp-agent group v3 group_traps privacy read-view view_iso notify-view view_iso
# USM uživatel se jménem 'trapper', heslem/klíčem pro autorizaci 'authpass' a pro šifrování 'privpass'
snmp-agent usm-user v3 trapper group_traps authentication-mode sha authpass privacy-mode aes128 privpass
# sada parametrů 'v3-trapper': SNMPv3, auth/priv podle USM uživatele 'trapper'
snmp-agent target-host trap-paramsname v3-trapper v3 securityname trapper privacy
# konkrétní příjemce oznámení 'nms'
snmp-agent target-host trap-hostname nms address 10.20.30.1 trap-paramsname v3-trapper
# aktivace funkce trap
snmp-agent trap enable standard

Pokud používáme automatické hledání nových ONT, tak nejprve projdeme tabulku nalezených ONT:

# = [cli] display ont autofind all
snmpbulkwalk $OPTS $AGENT \
    HUAWEI-XPON-MIB::hwGponDeviceAutoFindOntInfoTable

Tím zjistíme nejen sériové číslo, typ a verzi každého nalezeného ONT, ale také ifIndex portu, na kterém bylo nalezeno. V případě, že ONT přidáváme předem (ještě není zapojeno), tak si ifIndex musíme zjistit.

V dalším kroku najdeme volné ONT ID (dále označováno jako $ONT). „Vedlejším“ produktem následujícího příkazu jsou totiž indexy ONT (hwGponDeviceOntIndex). Procházíme ale sloupec hwGponDeviceOntEntryStatus, protože ten je na rozdíl od hwGponDeviceOntIndex přístupný (má přístupový režim read-create).

# ~ [cli] display ont info $F $S $P all
snmpbulkwalk $OPTS -Cr128 $AGENT \
    HUAWEI-XPON-MIB::hwGponDeviceOntEntryStatus.$IFIDX

A nyní už máme vše potřebné pro přidání nového ONT:

# = [cli] interface gpon $F/$S; ont add $P $ONT sn-auth 01234567890ABCDEF omci ...
snmpset $OPTS -m HUAWEI-XPON-MIB $AGENT \
    hwGponDeviceOntAuthMethod.$IFIDX.$ONT = sn \
    hwGponDeviceOntSn.$IFIDX.$ONT x 0123456789ABCDEF \
    hwGponDeviceOntManagementMode.$IFIDX.$ONT = omci \
    hwGponDeviceOntEntryStatus.$IFIDX.$ONT = createAndGo \
\ # ... [cli] ont-lineprofile-name LP2 ont-srvprofile-name SP3 desc "Jan Novak"
    hwGponDeviceOntLineProfName.$IFIDX.$ONT = LP2 \
    hwGponDeviceOntServiceProfName.$IFIDX.$ONT = SP3 \
    hwGponDeviceOntDespt.$IFIDX.$ONT = "Jan Novak"

Individuální nastavení DBA se provádí v tabulce HUAWEI-XPON-MIB::hwGponDeviceLineProfTcontRefTable. Tato tabulka má zvláštní chování: při procházení jsou v ní všechny T-CONTy, tj. i ty, které mají DBA nastaveno v ont-lineprofile gpon (zajímavost: lze zde zjistit i aktuální Alloc-ID všech T-CONT). Nepřiřazené (unbound) T-CONTy mají v hwGponDeviceLineProfTcontName prázdný řetězec, v hwGponDeviceLineProfAllocId mají hodnotu -1, ale v tabulce existují. Přesto se přiřazení provádí „vytvořením“ příslušné řádky (createAndGo) a ruší „smazáním“ řádky (destroy). Slova píšu v uvozovkách, protože řádka existuje po celou dobu - jen to způsobí nastavení sloupce hwGponDeviceLineProfTcontName na jméno DBA profilu nebo na prázdný řetězec. Po nastavení vypadá individuálně zkonfigurovaný T-CONT stejně, jako T-CONTy zkonfigurované profilem (nelze je mezi sebou rozeznat čtením tabulky hwGponDeviceLineProfTcontRefTable).

# = [cli] interface gpon $F/$S; tcont bind-profile $P $ONT $TCONT profile-name "$DBA"
snmpset $OPTS -m HUAWEI-XPON-MIB $AGENT \
    hwGponDeviceLineProfTcontName.$IFIDX.$ONT.$TCONT = "$DBA" \
    hwGponDeviceLineProfTcontRefEntryStatus.$IFIDX.$ONT.$TCONT = createAndGo

# = [cli] interface gpon $F/$S; undo tcont bind-profile $P $ONT $TCONT
snmpset $OPTS -m HUAWEI-XPON-MIB $AGENT \
    hwGponDeviceLineProfTcontRefEntryStatus.$IFIDX.$ONT.$TCONT = destroy

Tabulka HUAWEI-XPON-MIB::hwGponDeviceOntPortVlanTable obsahuje jen individuálně nastavené VLAN (tj. neobsahuje VLAN nastavené v ont-srvprofile gpon). Index v této tabulce má 7 složek (!), některé jsou jasné, další vysvětlujeme aspoň krátce v komentáři v příkladu. Vybrali jsme nejčastější variantu ont port vlan, která se používá třeba pro čtyřportová ONT sdílená více uživateli - q-in-q $SVLAN user-vlan untagged. Jiné varianty (značkované klientské VLAN a pod.) snadno otestujete tím, že konfiguraci vytvoříte v příkazové řádce a pak si projdete výsledek v tabulce hwGponDeviceOntPortVlanTable.

# = [cli] interface gpon $F/$S; ont port vlan $P $ONT eth $ETH q-in-q $SVLAN user-vlan untagged
snmpset $OPTS -m HUAWEI-XPON-MIB $AGENT \
    hwGponDeviceOntPortVlanCfgType.$IFIDX.$ONT.eth.$ETH.65533.4294967295.4294967295 = qinq \
    \ # 65533 = c-untagged v q-in-q, 4294967295 (= -1) = c-prio undefined, 4294967295 (= -1) = c-encap any
    hwGponDeviceOntPortVlanSVlan.$IFIDX.$ONT.eth.$ETH.65533.4294967295.4294967295 = $SVLAN \
    hwGponDeviceOntPortVlanRowStatus.$IFIDX.$ONT.eth.$ETH.65533.4294967295.4294967295 = createAndGo

Indexy (čísla) služeb jsou v SNMP o jedničku vyšší, než v příkazové řádce. To vyjadřuji níže zápisem $(($SP+1)), kde $SP je číslo z příkazové řádky. Podobně jsou o jedničku posunuty indexy v traffic table ip. Pokud při definici služby neznáme vhodné volné číslo, zjistíme ho nejprve z proměnné HUAWEI-ETHERLIKE-EXT-MIB::hwExtSrvFlowIndexNext (i ta obsahuje $(($SP+1)), které můžeme následně přímo v SNMP použít pro vytvoření nové služby).

# = [cli] service-port $SP ...
snmpset $OPTS -m HUAWEI-ETHERLIKE-EXT-MIB $AGENT \
    # ... [cli] vlan $VLAN gpon $F/$S/$P ont $ONT gemport $GEM ...
    hwExtSrvFlowPara1.$(($SP+1)) = $F \
    hwExtSrvFlowPara2.$(($SP+1)) = $S \
    hwExtSrvFlowPara3.$(($SP+1)) = $P \
    hwExtSrvFlowPara4.$(($SP+1)) = $ONT \
    hwExtSrvFlowPara5.$(($SP+1)) = $GEM \
    hwExtSrvFlowParaType.$(($SP+1)) = gpon \
    hwExtSrvFlowVlanid.$(($SP+1)) = $VLAN \
    \
    \ # - a) ... [cli] [ tag-transform default ] ...
    hwExtSrvFlowMultiServiceType.$(($SP+1)) = singleService \
    \ # - b) ... [cli] multi-service user-vlan $UVLAN [ tag-transform translate ] ...
    hwExtSrvFlowMultiServiceType.$(($SP+1)) = byUserVlan \
    hwExtSrvFlowMultiServiceUserPara.$(($SP+1)) = $UVLAN \
    \ # - c) ... [cli] multi-service user-vlan $UVLAN user-encap (ipv4oe|ipoe|pppoe|ipv6oe) [ tag-transform translate ] ...
    \ #                                                   $ENCAP:    0  |  1 |   2 |   3 
    hwExtSrvFlowMultiServiceType.$(($SP+1)) = byVlanEncap \
    hwExtSrvFlowMultiServiceUserPara.$(($SP+1)) = $((($ENCAP<<13)+$UVLAN)) \
    \
    hwExtSrvFlowRowStatus.$(($SP+1)) = createAndGo \
    \
    \ # - a) ... [cli] inbound traffic-table index $TX_CTTR outbound traffic-table index $RX_CTTR
    hwExtSrvFlowTransmitTrafficDescrIndex.$(($SP+1)) = $(($TX_CTTR+1)) \
    hwExtSrvFlowReceiveTrafficDescrIndex.$(($SP+1)) = $(($RX_CTTR+1)) \
    \ # - b) ... [cli] inbound traffic-table name "$TX_NAME" outbound traffic-table index "$RX_NAME"
    hwExtSrvFlowInboundTrafficTableName.$(($SP+1)) = "$TX_NAME" \
    hwExtSrvFlowOutboundTrafficTableName.$(($SP+1)) = "$RX_NAME" \
    \
    \ # + [cli] service-port desc $SP description "$DESC"
    hwExtSrvFlowDescInfo.$(($SP+1)) = "$DESC" \
    \ # + [cli] service-port remote-desc $SP description "$REM_DESC"
    hwExtSrvFlowRemoteDescInfo.$(($SP+1)) = "$DESC"

MIB neimplementuje obdobu příkazu display service-port port, kterým bychom si zjistili všechny služby definované pro jedno konkrétní ONT. Pokud znáte i parametry služby (číslo GEM a rozlišení služby na straně ONT - např. víte, že jsou služby na GEM rozlišeny pomocí VLAN značek a znáte tyto značky), můžete se dotázat tabulky HUAWEI-ETHERLIKE-EXT-MIB::hwFlowIndexQueryTable. Tuto tabulku není možné procházet pomocí get-next-request (snmpwalk), musíte se dotázat na konkrétní hodnotu hwFlowIndex tím, že v dotazu pošlete kompletní index:

# = [cli] display service-port port $F/$P/$
#   (konrétně pro 'multi-service user-vlan $UVLAN')
snmpget $OPTS -m HUAWEI-ETHERLIKE-EXT-MIB $AGENT \
    hwFlowIndex.$IFIDX.gemPort.$ONT.$GEM.0.byUserVlan.$UVLAN

Pokud neznáte parametry rozlišení GEM, musíte projít celou tabulku hwExtSrvFlowTable:

snmpbulkwalk $OPTS -Cr512 -m HUAWEI-ETHERLIKE-EXT-MIB $AGENT \
    hwExtSrvFlowPara2 # $S
snmpbulkwalk $OPTS -Cr512 -m HUAWEI-ETHERLIKE-EXT-MIB $AGENT \
    hwExtSrvFlowPara3 # $P
snmpbulkwalk $OPTS -Cr512 -m HUAWEI-ETHERLIKE-EXT-MIB $AGENT \
    hwExtSrvFlowPara4 # $ONT

Takové procházení je samozřejmě pomalé. Načtení 1000 hodnot z jednoho sloupce trvá 500 ms (a to i při hromadném procházení po 512 položkách uvedeném výše), takže načtení 1000 hodnot ze všech tří sloupců bude trvat zhruba 1,5 sekundy (čtvrtý soupec, tj. hwExtSrvFlowPara1, jsme vynechali záměrně: je to $F, tedy při běžném provozu OLT vždy 0). Proto se u většího počtu operací vyplatí celou tabulku načíst a držet v paměti.

Pokud máte rychlou implementaci SNMP (která umí rychle sestavit velké dotazy), můžete dotaz na konkrétní ONT různě optimalizovat: projít například kompletně sloupec hwExtSrvFlowPara4, z výsledků vybrat jen ty řádky, které mají požadované $ONT, a pak pro sloupec hwExtSrvFlowPara3 poslat get-request se seznamem vybraných řádků. Tím se seznam opět zúží pro dotaz na sloupec hwExtSrvFlowPara2 (procházení začínáme sloupcem hwExtSrvFlowPara4, protože má ze všech tří nejvyšší počet možných hodnot, a tak rozdělí celou tabulku na nejmenší skupiny). I takto optimalizovaný dotaz bude trvat něco málo přes 500 ms pro každých 1000 služeb.

Oba způsoby (hwFlowIndexQueryTable a procházení hwExtSrvFlowTable) je možné i kombinovat. Například chcete zjistit seznam služeb na konkrétním ONT, abyste toto ONT mohli smazat. Pošlete dotaz na hwFlowIndexQueryTable pro všechny známé $UVLAN. Výsledné služby smažte a pak zkuste smazat ONT. Pokud mazání ONT vrátí chybu, tak přejděte k plnému procházení hwExtSrvFlowTable.