Śledzenie nieprawidłowego źródłowego adresu mac

Odziedziczyłem obsługę zdalnej strony, która zawiera Cisco 4500 i jest podłączona do ~ 2 tuzinów przełączników dostępowych cisco - głównie 2960 z kilkoma 3750 i 3560. Nie wszystkie przełączniki dostępu są bezpośrednio podłączone do 4500 - istnieje pewne szeregowe połączenie przełączników, które najwyraźniej zostało wykonane w wyniku nieodpowiedniego okablowania. Ostatnio zauważyłem komunikaty o błędach na 4500, które wskazują, że otrzymano ramki z niepoprawnym źródłowym adresem mac:

*Sep 10 09:29:48.609: %C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: (Suppressed 102563 times)Packet received with invalid source MAC address (00:00:00:00:00:00) on port Te5/1 in vlan 1460

Urządzeniem podłączonym do Te5 / 1 jest przełącznik dostępu (Cisco 3750). To z kolei jest połączone z 6 innymi przełącznikami dostępu. Po odrobinie googlingu wygląda na to, że 4500 jest jedyną platformą cisco, która rejestruje nieprawidłowe źródłowe adresy mac. Z mojego czytania wynika, że inne platformy (2960, 3750 itp.) Wydają się przesyłać dalej ramki, ale nie rejestrują ich jako nieprawidłowe, ani nie dodają wpisu do tablicy adresów mac. Podejrzewam, że główną przyczyną nieprawidłowych źródłowych adresów mac może być wadliwa nic, błąd oprogramowania lub błędnie skonfigurowany serwer vmware. Jakie narzędzia są dostępne na przełącznikach dostępu, aby wyśledzić naruszający port?

cisco switch layer2

— Użytkownik123456
źródło

Usunąłem mój post, nie zdawałem sobie sprawy, że wcale nie były widoczne. Jeśli przełącznik nie umieści ich w CAM, myślę, że najlepszym rozwiązaniem jest uruchomienie sesji SPAN na przełącznikach, ale nawet wtedy trudno byłoby znaleźć port źródłowy. Inną opcją byłoby wyłączenie nieznanej emisji pojedynczej i sprawdzenie, czy coś się psuje. Jestem zaskoczony, że komunikacja działa. Jeśli host z tym MAC wysyła coś poza jego podsieci, GW musiałby ARP, aby zobaczyć MAC hosta i enkapsulować ramkę, czy GW ma jakieś dziwne mapowania ARP?

— Daniel Dib,

Według strony supportforums.cisco.com/docs/DOC-36000 te ramki powinny zostać upuszczone w HW, aby przynajmniej nie wpłynęło to na wydajność przełączników.

— Daniel Dib,

Tak, zgodnie z tym linkiem: „Pamiętaj, że pakiety z nieprawidłowym adresem MAC i tak zostaną odrzucone, wszystkie inne przełączniki Cisco Catalyst po cichu upuszczają te pakiety w HW, platforma 4k wyraźnie generuje komunikat rejestrowania, gdy takie zdarzenie zostanie zaobserwowane”. ... ale wiem, że tak nie może być, ponieważ 4500 narzeka na ramki przychodzące na Te5 / 1, który jest portem podłączonym do 3750. Oznaczałoby to, że 3750 przesyła ramki z / nieważnym źródło Mac pomimo tego, co mówi DOC-36000.

— User123456,

Dziel i rządź!

— generalnetworkerror

Czy jakaś odpowiedź ci pomogła? jeśli tak, powinieneś zaakceptować odpowiedź, aby pytanie nie wyskakiwało wiecznie, szukając odpowiedzi. Alternatywnie możesz podać i zaakceptować własną odpowiedź.

— Ron Maupin

Odpowiedzi:

Możesz spróbować sprawdzić, czy ramki można zablokować za pomocą MAC ACL na interfejsach i / lub na sieciach VLAN na przełącznikach dostępu. Stosując bloki wybiórczo i sprawdzając, czy komunikaty o błędach na 4500 znikają, czy nie, możesz wrócić do źródła ruchu.

Przenoszenie kabli w celu sprawdzenia, czy port wymieniony w komunikacie o błędzie na 4500 poniżej może również pomóc, ale może okazać się trudne w środowisku produkcyjnym.

— Gerben
źródło

Zasadniczo, gdy to widzę, pochodzi od źle skonfigurowanej maszyny wirtualnej (często hostowanej na komputerze użytkownika). W zależności od sytuacji i środowiska mogą być trudne do wyśledzenia (widziałem wiele z nich na uniwersytecie w budynkach departamentu CS i ECE, które poruszały się i przychodziły / odchodziły tak jak studenci).

Masz już kilka świetnych odpowiedzi, ale inną opcją, którą możesz zastosować, jest dodanie następującej konfiguracji do przełączników downstream (37xx, 36xx, 29xx):

   mac address-table static 0000.0000.0000 vlan <VLAN ID> drop

Spowoduje to spadek ruchu przy użyciu tego MAC, a nie przekazywanie go dalej, a ponieważ należy to zrobić sprzętowo (z wyjątkiem jakichkolwiek funkcji / problemów, które powodują wyszukiwanie adresów MAC w oprogramowaniu), nie powinno to mieć negatywnego wpływu na wydajność.

— YLearn
źródło

Dziękuję za tę sugestię. Zapobiegnie to przekazywaniu ramek przez pnie do innych przełączników, co jest dużą wygraną. Czy istnieje sposób, za pomocą komend logowania lub debugowania, aby obserwować ramki upuszczające porty na podstawie tej konfiguracji?

— User123456,

@fcrarao, niestety nie w tej konfiguracji. Będziesz musiał spróbować zrobić to, co zasugerował Gerben, i skorzystaj z MAC ACL lub sugestii Dave'a, aby przechwycić ruch poza portami. Uważam jednak, że negatywnie wpłynie to tylko na źle skonfigurowane urządzenie, więc albo to ujawnią, albo nawet nie zauważą.

— YLearn

Wydaje mi się, że ten błąd nie wpływa na wydajność sieci, ponieważ samodzielnie odkryłeś komunikaty dziennika, a nie jesteś zalany skargami użytkowników. To prowadzi mnie do podejrzeń, że problem dotyczy niektórych połączonych, ale częściowo skonfigurowanych lub źle skonfigurowanych programów lub usług, które nie są obecnie używane.

Najlepszym rozwiązaniem może być pozostawienie tego śpiącego psa do czasu, aż jakiś użytkownik zgłosi problem. Alternatywnie, jeśli masz czas do stracenia, możesz uruchamiać sesje SPAN, jak sugerował @Daniel Dib, i dokładnie analizować dane wyjściowe do momentu ustalenia podejrzanego portu lub urządzenia.

— Dave w Ohio
źródło