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?
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é...
