Irgendwie scheinen sich Cisco-Komponenten nicht so ganz mit VMWare zu vertragen.
Wer so ganz der Schuldige ist, weiß ich noch nicht. Jedenfalls scheint VMWare (zumindestens der Player) selbst bei einer Bridge-Netzwerkverbindung in die Pakete reinzupfuschen. Genauer: DHCP-Pakete werden modifiziert.
Während normalerweise bei einer Bridge die MAC-Adresse der virtuellen Maschine verwendet wird, wird das DHCP-Discover-Paket mit der MAC-Adresse des Hosts versendet. D.h. die MAC-Adresse auf Layer 2 stimmt nicht mit der Client-Adresse im DHCP-Paket auf Layer 7 überein. Eigentlich nicht so schlimm, wenn da nicht die Cisco-Geräte übel drauf reagieren würden.
Problem Nr 1
Die Cisco ASA meldet eine ARP Request collision:
Message: Received ARP request collision from x.y.45.150/0024.d700.0001 on interface WLAN with existing ARP entry x.y.45.150/000c.2900.0002
Allerdings ist alles korrekt - die virtuelle Maschine mit der MAC 000c.2900.0002 hat vom DHCP die x.y.45.150 zugeteilt bekommen und der Host (0024.d700.0001) eine völlig andere per DHCP.
Dieses Problem könnte man fast noch ignorieren - wenn nicht die Warnsysteme anschlagen würden und ein Ticket automatisch öffnen
Problem Nr 2
Das nächste Problem ist noch viel schlimmer. Diesmal ist nicht die Cisco ASA sondern ein Cisco Catalyst C3560-E die "störende" Komponente. Ohne DHCP-Snooping funktioniert alles wunderbar. Sobald man aber aus Sicherheitsgründen DHCP-Snooping aktiviert, bekommen virtuelle Maschinen keine DHCP-Antworten mehr. Das ganze völlig ohne Log-Eintrag oder irgendwelchen Hinweis vom Switch!
Erst Debugging vom DHCP Snooping zeigte mir den Fehler:
Nov 4 10:15:07.524: DHCP_SNOOPING: received new DHCP packet from input interface (GigabitEthernet0/49)
Nov 4 10:15:07.524: DHCP_SNOOPING: process new DHCP packet, message type: DHCPDISCOVER, input interface: Gi0/49, MAC da: ffff.ffff.ffff, MAC sa: 0024.d700.0001, IP da: 255.255.255.255, IP sa: 0.0.0.0, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 000c.2900.0002
Nov 4 10:15:07.524: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (1402)
Nov 4 10:15:07.533: DHCP_SNOOPING: received new DHCP packet from input interface (GigabitEthernet0/6)
Nov 4 10:15:07.533: DHCP_SNOOPING_SW: client address lookup failed to locate client interface, retry lookup using packet mac DA: ffff.ffff.ffff
Nov 4 10:15:07.533: DHCP_SNOOPING_SW: lookup packet destination port failed to get mat entry for mac: 000c.2900.0002
Nov 4 10:15:07.533: DHCP_SNOOPING: process new DHCP packet, message type: DHCPOFFER, input interface: Gi0/6, MAC da: ffff.ffff.ffff, MAC sa: 001d.a2AA.BBCC, IP da: 255.255.255.255, IP sa: x.y.45.254, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: x.y.45.150, DHCP siaddr: 0.0.0.0, DHCP giaddr: x.y.45.254, DHCP chaddr: 000c.2900.0002
Nov 4 10:15:07.533: DHCP_SNOOPING_SW: client address lookup failed to locate client interface, retry lookup using packet mac DA: ffff.ffff.ffff
Nov 4 10:15:07.533: DHCP_SNOOPING_SW: lookup packet destination port failed to get mat entry for mac: 000c.2900.0002
Nov 4 10:15:07.541: DHCP_SNOOPING: can't find output interface for dhcp reply. the message is dropped.
Man erkennt hier wunderbar, dass die MAC-Adresse beim DHCP-Discover unterschiedlich ist. Das Antwortpaket wird aber korrekterweise an 000c.2900.0002 geschickt. Diese MAC-Adresse ist dem Switch aber unbekannt, da ja bislang kein Paket mit der Absender-MAC am Switch einging...
Jetzt ist nur noch die Frage wie Cisco auf die beiden Bugs reagiert...