Traffic, kterej tam nemá být

[sub_zero]

Ahoj,

poslední dobou začínám pozorovat zvláštní anomálii.
Na jednom sajtu máme switch (HP2510-24), do něj jsou zapojený přes PoE jednotlivý access pointy a ptp spoje. Tyto spoje jsou klasicky nastavený jako AP, tzn. eth + wlan do bridge. Routuje se až u kliošů. Prostě klasickej příklad. Toť popis, teď příklad.

Např. klient 1 je připojenej na access point A. Když klient komunikuje, udělám si na tom access pointu A Torch na ifacu, vidím jeho ipku, kam komunikuje atd. Ale stává se, že toho samýho klienta uvidím jak komunikuje i na access pointu B. Sice tam vidím pouze jednostranou komunikaci (posílání na IP adresu toho klienta), ale rychlost bejvá i 1-2mbit a narostou na klienty odezvy do 100ms.
Když to je broadcast, tak to chápu, ale unicast se takto chovat nesmí. Nemáte nějakej tip, co prověřit? Mám takovej pocit, že to začlo až pri upgradu na v6, ale jistej si nejsem.

Díky.

[Dalibor Toman]

Ahoj,

poslední dobou začínám pozorovat zvláštní anomálii.
Na jednom sajtu máme switch (HP2510-24), do něj jsou zapojený přes PoE jednotlivý access pointy a ptp spoje. Tyto spoje jsou klasicky nastavený jako AP, tzn. eth + wlan do bridge. Routuje se až u kliošů. Prostě klasickej příklad. Toť popis, teď příklad.

Např. klient 1 je připojenej na access point A. Když klient komunikuje, udělám si na tom access pointu A Torch na ifacu, vidím jeho ipku, kam komunikuje atd. Ale stává se, že toho samýho klienta uvidím jak komunikuje i na access pointu B. Sice tam vidím pouze jednostranou komunikaci (posílání na IP adresu toho klienta), ale rychlost bejvá i 1-2mbit a narostou na klienty odezvy do 100ms.
Když to je broadcast, tak to chápu, ale unicast se takto chovat nesmí. Nemáte nějakej tip, co prověřit? Mám takovej pocit, že to začlo až pri upgradu na v6, ale jistej si nejsem.

Díky.

a neloguje ten switch (pokud to umi, HPcka neznam) nejaky hlasky indikujici preplneni bridgeovaci tabulky? Kolik ma v dobe problemu MACek v te tabulce? Pokud by mel malo mista na MACky a byla za nim rozsahlejsi sit, je mozne, ze pri nejakem scanu IPcek se zahlti a bude nektery provoz posilat na vsechny porty.

Pak by jeste mohlo dojit k tomu, ze se ti 2 klienti propoji mezi nejak sebou (ale pokud na CPE routujes nemelo by to pres AP vytvorit L2 smycku). Pripadne se muze nejaky MT AP chovat nejak divne a injektovat zpet MACku, ktera k nemu vubec neni pripojena. Rozumny switch by logoval flapovani MAcky...

[Majklik]

Nevhodně zvolené bojové prostředky pro danou situaci. Prvně vždy do zahradního jezírka naházíme několik obranných ručních granátů (použit packet sniffer na tom bridge na APčkách), pak dáme pojistnou dávku-dvě z AKčka (netwatch) a pak se jdeme podívat, zda z těch zbytků půjde poznat, jestli šlo o zloděje vtipně se schovávající v našem jezírku nebo soused zase lovil svého zaběhlélo leguána (show mac-address na tom HP)... A pak volám svého právníka, že mám pro něj velice zajimavý případ, kdy to bude muset uhrát na nutnou sebeobranu (možná na tom HP mac-count-trap?)....

To vypadá na L2 problém. Ten klient1 by měl být za nějakou MAC1, takže bych se prvně podíval packet sniferem, že ten tok na IP klient1 má správnu MAC1 adresu (a patřičně na routeru, který to do toho L2 segmentu strká, zda jeho ARP tbulka má správné mapování), a pak, zda patřičně HP vidí tu MAC1 na portu, kde má apA. Na apA v /interface bridge host musím vidět MAC1 stabilně mířííc do rádia, na ostatních APčkách mířících do HP switche.
Pokud HP dostane unicast paket pro neznámou MAC, tak pošle do všech portů (v HP bylo něco jako mac-count-notify pro varování, když je toho na portech moc), což by odpovídalo popsané situaci. Stejně tak, kdyby tomu HP přetákala forward tabulka, ale snad 8000 krámů tam nemáš v jedné L2 (jeden fyzický krám zapojený do deseti VLAN samozřjmě žere 10 položek ve forward tabulce)?
Jestli HP má zblbý forward a APčka ho mají dobře, tak sice ten tok do APček přijde, ale neměly by ho poslat do rádií.

[sub_zero]

Tak jsem vse prolezl a sedi to. MAC1 klienta1 je pouze na wlan ifacu toho bridge a toho APcka, kam je pripojenej, na ostatnich APckach na etheru videt jeho MAC1 neni, po propingnuti se tam objevi.
Ono se to nedeje porad, spis nekdy k veceru, kdyz je spicka. ¨

Problem je ale na tom switchi.. kdyz se kouknu na port show mac-address 3, kam je APcko, na kterym je ten klient1 zapojenej, tak jeho MAC1 ve vypisu neni!
A nenasel jsem ho ani na uplink portu... Pritom komunikace normalne probiha, na toho klienta se dostanu... Co je spatne? :/

Jen upresnim, ze ten klient je stara NS5. Dalsi dve NS5, co jsou na stejnym AP jsou normalne na portu switche videt.

[Majklik]

Pokud nemá HP switch v bridge tabulce tu MAC1 naučenou, posílá data pro danou MAC1 do všech portů (vyjma toho, kterým to přišlo). To vysvětluje, proč to vidíš na APčkách, kde nemáš.
Ty další bridge na AP tam tu MAC1 nemusí mít trvale, pokud danou MAC1 zrovna neslyší jako zdohovou v nějakém paketu.

Na ostatních routerech na tom L2 segmentu, když se podíváš do ARP tabulek. Po napingnutí IP1, sedí mapování IP1:MAC1?
Pinkni přímo z apA, oveř to na jiném apX a také na tom, co tomu dělá defualt bránu.

Proč se ten switch na tom portu nenaučí tu MAC může mít vysvětlení, že datový tok od IP1 neodchází s MAC adresou, kterou vrací do ARP odpovědí. ARP odpověď ve své odchozí L2 MAC adresu má také něco jiného, ale uvnitř ARP dat je ta správná MAC adresa. Tím pádem se naučí ARP tabulky správnou MAC adresu, na tu posílají data, ale switch nezná správnou MAC a broadcastuje to. Zda by to mohlo být tímto, tak packet sniffer na tom portu 3 u HP a podívat se, co z toho leze v paketech od klienta. Možná by stačili se podívat na tom apA na ether port směr do HP switche, jaké MAC jsou v datech od IP1 jako odchozí, zda souhlásí s tou, co je propagována v ARP. Příznakem by mohlo být, že switch na show mac-address 3 vidí i jinou MAC, než legální klienti plus to APčko.
Dále na tom portu můžeš mít nastavne limit MAC adres, kolik jich to vezme, pokud máš nastaven limit, ale nemáš nastavneu politiku co s MAC adresama nad plán, tak by se to mohlo takto chovat. U HP něco jako aaa port-access client-limit? Možná, něco by mohl říci show port-security intrusion-log. V show port-access summary by mohlo být vidět, zda nemáš nastaveny nějaké limity na port na počet MAC adresy.
Omylem zapnuté proxy ARP na tom apA by mohlo vést k podobnému chování, kdy odchozí provoz od klienta se maskuje za MAC APčka. Samozřejmě bridge L2 NAT také...

[Dalibor Toman]

Tak jsem vse prolezl a sedi to. MAC1 klienta1 je pouze na wlan ifacu toho bridge a toho APcka, kam je pripojenej, na ostatnich APckach na etheru videt jeho MAC1 neni, po propingnuti se tam objevi.
Ono se to nedeje porad, spis nekdy k veceru, kdyz je spicka. ¨

propingnutim se mysli co? Odkud se pinga? Pokud se po pingu dejme tomu z nejake gatewaye objevi MACka klienta i na APckach, kde neni pripojenej tak je to podezrele. Nastat by to mohlo pouze pokud klient nema v ARP tabulce zaznam pro tu gateway (a musi vyrobit ARP broadcast, ktery se dostane i na ostatni APcka). Zkusil bych :
pustit ping a pak na nejakem AP kde neni pripojen klient kontrolovat zda se tam MAC klienta dostane. Pokud ano pak bych ji smaznul a dival se (ping stale bezi), jestli skoci zpet. Pokud ano tak je problem

Problem je ale na tom switchi.. kdyz se kouknu na port show mac-address 3, kam je APcko, na kterym je ten klient1 zapojenej, tak jeho MAC1 ve vypisu neni!
A nenasel jsem ho ani na uplink portu... Pritom komunikace normalne probiha, na toho klienta se dostanu... Co je spatne? :/

Jen upresnim, ze ten klient je stara NS5. Dalsi dve NS5, co jsou na stejnym AP jsou normalne na portu switche videt.

takze ten switch nema tu MACku ve forwardovaci tabulce? Chtelo by to proverit umi to HPcko spustit nejake hledani ve vypisu pres celou tabulku? Pokud fakt neni ta MACka ve forwardovaci tabulce tak je to problem. A jedine duvody pro to aby tam nebyla me napadaji tyto:
- uz zminene preplneni forwardovaci tabulky (at fyzicky nebo prekroceny nejaky nastaveny limit)
- ta MAC je nejaka 'divna' - neni nahodou rucne predefinovana? - jaky je jeji prvni byte (zleva)?
- nejaky filtr na switchi
- chyba switche

Jeste me napada - nema ten switch nastaveny timeout na vyhazovani MACek z pameti na nejakou silene nizkou hodnotu? Pak bys mozna (pokud na tu MACku je maly provoz) ji nemusel stihnout na switchi najit

[Majklik]

Chtelo by to proverit umi to HPcko spustit nejake hledani ve vypisu pres celou tabulku? Pokud fakt neni ta MACka ve forwardovaci tabulce tak je to problem.

show mac-address aaaaaa-bbbbbb

- ta MAC je nejaka 'divna' - neni nahodou rucne predefinovana? - jaky je jeji prvni byte (zleva)?

To je pravda, natrefeně zapnutí multicast bit udělá své.

Jeste me napada - nema ten switch nastaveny timeout na vyhazovani MACek z pameti na nejakou silene nizkou hodnotu? Pak bys mozna (pokud na tu MACku je maly provoz) ji nemusel stihnout na switchi najit

HP má asi jako minimum 60 sekund. Mění se přes mac-age-time X.

[sub_zero]

Proxy ARP zapnuté není, kontroloval jsem.
Pustil jsem ping z gatewaye na tu IP toho klienta. NA ostatních AP jeho MAC nebyla, pouze na AP, kde je připojen a to na správném ifacu (wlan1). Na gateway vrací správnu MAC.
Ovšem na switchi na portu 3 stále není. Co se nastavení switche týče, tak je tam asi 20 VLANů, žádná port securita ani MAC timeout. Intrusion log je prázdnej.
Zkusím ještě ten sniffer.
JInak MAC kleinta je 00:15:6D:BB:A5:34 Jak jsem psal, je to stará mrdka NS5, sice sem tam nalil poslední fw, ale těžko říct. Co sem zatím vypozoroval, tak žádný jiný klient to nedělá.

edit:

Kód: Vybrat vše

hp51-chema.sigmasoft.cz# show mac-address 00156d-bba534

Status and Counters - Address Table - 00156d-bba534

MAC address 00156d-bba534 not found.


což je zřejmě špatně...

[Majklik]

Pokud ti aktuálně běží tne ping gateway-IP1, tak rozhodně je špatně, že nevidí switch tu MAC ve své bridge tabulce.
Když dáš ping na IP1 z brány, tak se MAC1 neukáže na dalších AP, protože klient odpovídá bráně pomocí unicastu. To by se z toho klienta muselo zkusit třeba ping někam na IP v tom segmentu na nějakou neplantou IP, aby klient vyslal L2 broadcast paket všem jako ARP dotaz, teprve potom ho uvidí další AP ve svém bridge (nwbo když přes ně půjde nějaý unicastový provoz od dané MAC1).

[sub_zero]

Takže řešení bude zkusit vyměnit to NS5, co? Nebo zkusit to AP do jinýho portu v tom switchi?

[Majklik]

Strčit do jiného portu je možnost, vyloučíš problém portu.
Ten packet sniff na tom AP1 na ether portu je snad na 10 sekund a uvidíš, zd z toho leze správná MAC.
Nebo jeslti je brána ven také ROS, tka si můžeš tne sniff pustit na portu brány.

[sub_zero]

sniff.png (81.92 KiB) Zobrazeno 2465 x

vypadá to ok... MAC sedí. Zkoušel jsem i najít ostatní MAC klientů, kterí jsou připojení přes stejné AP a všechny na tom portu switche jsou. Jen tahle ne...

edit: na dalším switchi směrem k bráně je ta MAC viděl na správném portu..

[Dalibor Toman]

neexistuje na ten HP switch nejakej novejsi firmware? - zacal bych tam.

Zacina to byt z poslednich informaci ponekud divne - switch MACku nezna a presto se tam MAC ted neobjevi na eth dalsich AP (switch by ji tam mel protlacit tim ze by mel posilat packety pro tu MAC na vsechny porty). To by spise napovidalo, ze v tu chvili switch funguje OK ale z nejakeho duvodu tu MACku nezobrazi pri vypisu forwardovaci tabulky (btw stejnou chybu ma ROS 5.20 - bridge hosts nezobrazi uplne celou)

[Majklik]

vypadá to ok... MAC sedí. Zkoušel jsem i najít ostatní MAC klientů, kterí jsou připojení přes stejné AP a všechny na tom portu switche jsou. Jen tahle ne...

edit: na dalším switchi směrem k bráně je ta MAC viděl na správném portu..

Jo, to dost vylučuje možnost blbé zdrojové MAC, zvláště pokud další switch v řadě ji pak vidí správně.

switch MACku nezna a presto se tam MAC ted neobjevi na eth dalsich AP (switch by ji tam mel protlacit tim ze by mel posilat packety pro tu MAC na vsechny porty). To by spise napovidalo, ze v tu chvili switch funguje OK ale z nejakeho duvodu tu MACku nezobrazi pri vypisu forwardovaci tabulky (btw stejnou chybu ma ROS 5.20 - bridge hosts nezobrazi uplne celou)

Prohazješ zdrojovou a cílovou MAC.
Když něco vysílá pro tu MAC1, tka HP switch to pošle všude. Ty AP slyší tu MAC1 na bridge jako cílovou a hledají kam to poslat a neučí se dle toho. Učí se, až když slyší paket, kde ta MAC1 je jako zdrojová. Takže když z MAC1 jede broadcast všude nebo cíleně něco tlačí unicastem do příslušného bridge.

Novějším firmware by se to testnout také mohlo, pokud je. Přepojit na jiný port, zda to bude blbnout stejně je další možnost.

[sub_zero]

Koukám na relase notes k těm firmwarum a našel jsem tohle:

Kód: Vybrat vše

MAC Authentication (PR_0000039884)— The configured MAC authentication timeout
period does not function properly

Ale kontroloval jsem nastavení a MAC timeout nastavenej nemám. Mě to na problém switche moc nepřijde, protože za posledních 14 dnů, co jsem to zjistil, to dělal vždy jen ten jeden klient (ale nejsem si na 100% jistej, nekontroloval jsem to vždy).
Teď do switche leju poslední firm, tak uvidíme.

edit:

Kód: Vybrat vše

hp51-chema.sigmasoft.cz# show mac-address 00156d-bba534

 Status and Counters - Address Table - 00156d-bba534

  MAC Address : 00156d-bba534
  Located on Port : 3

tak uvidíme, co to večer udělá