Huawei GPON a MAC Aging

Výstavba optických sítí, pokládky a průvěsy kabelů, administrativa.
rsaf
Příspěvky: 1778
Registrován: 13 years ago

Huawei GPON a MAC Aging

Příspěvekod rsaf » 5 days ago

Z prozatím nezjištěných důvodů u mě v síti došlo k smyčce v síti (pravděpodobně chybující - jednosměrně fungující 10G spoj nějak rozhodil MSTP). Mám v daném okamžiku popadané věci v dohledu, v LOGu na jednom ze switchů mám:

Kód: Vybrat vše

005609: Feb 11 18:22:14.814 Prague: %SW_MATM-4-MACFLAP_NOTIF: Host 20cf.xxxx.xxxx in vlan 802 is flapping between port Gi1/0/28 and port Gi1/0/27

V danou chvíli přestalo fungovat několik IPTV STB které jsou připojené IPTV VLAN na GPONu, v OLT od té doby vidím hlášky:

Kód: Vybrat vše

 29086    2020-02-11 18:31:37+01:00
  Source MAC got by non-network-sideports is the same as one learnt by network-side ports
  User-side FrameID:0, User-side SlotID:0, User-side PortID:0,
  Network-side FrameID:0, Network-side SlotID:8, Network-side PortID:0,
  MAC  address:18b8-xxxx-xxxx, VLAN ID:551


Výpis MAC na OLT pak ukazuje:

Kód: Vybrat vše

HuaOLT-1#sho mac-address all | include 18b8-xxxx-xxxx
  It will take some time, please wait...
  -----------------------------------------------------------------------
   SRV-P BUNDLE TYPE MAC            MAC TYPE F /S /P   VPI  VCI   VLAN ID
   INDEX INDEX
  -----------------------------------------------------------------------
       -     -  eth  18b8-xxxx-xxxx dynamic  0 /8 /0   -    -         551
   16596     -  gpon 18b8-xxxx-xxxx dynamic  0 /0 /1   11   551       551
  -----------------------------------------------------------------------

Prostě to vypadá, jako by OLT MAC adresu STB vidělo ze strany GPONu i ze strany UPLINKu.

Podle této diskuze https://forum.huawei.com/enterprise/en/ ... 685-100181 to vypadá, že takový to chybný záznam z MAC tabulky prostě nevytimeoutuje, dokud je MAC adresa živá na síti (uživatel by asi musel STB alespoň na 5min vypnout z elektriky, protože jinak to pořád dokola sahá na DHCP server...).

Na základě té diskuze jsem nastavil:

Kód: Vybrat vše

mac-address aging-mode  unidirectional

což situaci vyřešilo (duplicitní záznam po několika minutách zmizel - aging je tam defaultně nastaven na 300sec)

Jestli je to takto správně si úplně jistý nejsem, ale pokud by se něco podobného někomu stalo, může tohle pomoci. Chvíli mi trvalo než jsem se dopátral toho, co se děje...
0 x

Dalibor Toman
Příspěvky: 1250
Registrován: 7 years ago

Příspěvekod Dalibor Toman » 4 days ago

DD,
na full duplex radiove trasy se vyplati zapnout nejakou detekci obousmernosti UDLD apod.
0 x

rsaf
Příspěvky: 1778
Registrován: 13 years ago

Příspěvekod rsaf » 4 days ago

UDLD tam zapnuté je, ale já si také nejsem jistý tím, co a kde smyčku způsobil (ne všechny Cisco switche macflap logují), na rádiový spoj jsem to svedl na základě zkušeností z minulosti a také na základě toho, že je to v podstatě jediný kruh v té části sítě, kde by se teoreticky něco takového mohlo dít (všechny ostatní jsou v optice).

Připadá mi ale poměrně zvláštní chování OLT, které záznamy v MAC tabulce neexpiruje jen na základě toho "že tu mac někde vidí" a vlastně úplně kašle na to, odkud paket přišel. Proč takový stav vznikne je jedna věc (MACFLAPy třeba dělají klienti roamující mezi hotspoty. Pokud bych měl některé hotspoty připojené přes GPON, dělalo by to v tomhle stavu ještě úplné psí kusy).
0 x

Dalibor Toman
Příspěvky: 1250
Registrován: 7 years ago

Příspěvekod Dalibor Toman » 4 days ago

u cisco switchu automaticky zapinam na konzoli rucne "debug spann event", loguje to pak vic infa z xSTP a da se lepe poznat odkud to prislo.
Obcas nam v siti delaji bordel RB750 - dostane se do stavu, kdy jakoby odrazi packety zpet aniz by se zmenily SRC/DST MACky v packetu. To je pak radosti na Starem Belidle...
0 x

rsaf
Příspěvky: 1778
Registrován: 13 years ago

Příspěvekod rsaf » 4 days ago

Takhle mi kdysi odrážel pakety Grandstream iptel. Udělal to ve firmě 2x a letěl z okna ;-)
0 x


Zpět na „FTTx“

Kdo je online

Uživatelé prohlížející si toto fórum: loopie a 1 host