sebastian.f 10 Geschrieben 17. Dezember 2007 Melden Teilen Geschrieben 17. Dezember 2007 Hallo ich kämpfe seit mittlerweile einem Monat mit einem Recht komischen Problem in unserem Bladecenter und ich weis langsam echt nicht mehr weiter. Wir betreiben einige VMWare ESX und RedHat Enterprise Linux Server in unserem Bladecenter. Bei beiden Systemen gibt es ein Problem mit dem Failover zwischen den Netzwerkkarten. Die Systeme haben 2 Netzwerkkarten von denen beide an jeweils einem Cisco 3020 Blade Switch angeschlossen sind. Wenn wir jetzt das erste Interface auf dem ersten Bladeswitch auf "Shutdown" schalten, wird ein Failover auf dem ESX Server oder auf dem Redhat Server ohne Ping Verlust durchgeführt. Machen wir das gleiche mit dem zweiten Interface auf dem zweiten Switch, ist die Verbindung komplett weg und ich kann das Blade nicht mehr anpingen. Hat jemand eine Idee warum das Failover beim Ausfall der zweiten Karte nicht funktioniert? Kann das am Switch liegen? ARP Spoofing Protection oder sowas? Wir sind jetzt auch schon eine Weile mit dem VMWare Support an der Sache dran aber kriegen da leider auch nix raus... Im Anhang noch die Config der Cisco Switches: sw_w43_c7000b-confg.txt sw_w43_c7000a-confg.txt Zitieren Link zu diesem Kommentar
Otaku19 33 Geschrieben 18. Dezember 2007 Melden Teilen Geschrieben 18. Dezember 2007 Hm, solange die Anhänge nicht freigeschaltet sind kann dir niemand helfen...vielleicht kannst ja einfach die relevanten teile der Konfig posten ? Kann ja schließlich nicht viel sein. Zitieren Link zu diesem Kommentar
sebastian.f 10 Geschrieben 18. Dezember 2007 Autor Melden Teilen Geschrieben 18. Dezember 2007 Also hier ist die Config eines 3020, der andere hat fast das gleiche konfiguriert, habe ein paar IFs rausgeschnitten dammit die Zeilengrenze eingehalten wird: version 12.2 no service pad service timestamps debug uptime service timestamps log datetime service password-encryption ! hostname sw_w43_c7000A ! logging monitor informational enable secret ! no aaa new-model clock timezone cest 2 ip subnet-zero ! ip domain-name raibakwt.com ip name-server 10.42.50.50 ! ! ! no file verify auto spanning-tree mode pvst spanning-tree extend system-id ! vlan internal allocation policy ascending ! interface Port-channel1 description Verbindung nach sw_w43_keller switchport trunk encapsulation dot1q switchport mode trunk ! interface FastEthernet0 no ip address no ip route-cache shutdown ! interface GigabitEthernet0/1 description ESX001 Int 1 switchport trunk encapsulation dot1q switchport trunk allowed vlan 2,13 switchport mode trunk speed 1000 spanning-tree portfast ! interface GigabitEthernet0/2 description ESX002 Int 1 switchport trunk encapsulation dot1q switchport trunk allowed vlan 2,13 switchport mode trunk speed 1000 spanning-tree portfast ! interface GigabitEthernet0/3 description ESX003 Int 1 switchport trunk encapsulation dot1q switchport trunk allowed vlan 2,13 switchport mode trunk speed 1000 spanning-tree portfast ! interface GigabitEthernet0/4 switchport mode access speed 1000 spanning-tree portfast ! interface GigabitEthernet0/5 switchport mode access speed 1000 spanning-tree portfast ! interface GigabitEthernet0/6 switchport mode access speed 1000 spanning-tree portfast ! interface GigabitEthernet0/15 speed 1000 spanning-tree portfast ! interface GigabitEthernet0/16 speed 1000 spanning-tree portfast ! interface GigabitEthernet0/17 description Etherchannel nach sw_w43_keller switchport trunk encapsulation dot1q switchport mode trunk channel-group 1 mode desirable ! interface GigabitEthernet0/18 description Etherchannel nach sw_w43_keller switchport trunk encapsulation dot1q switchport mode trunk channel-group 1 mode desirable ! interface GigabitEthernet0/19 description Etherchannel nach sw_w43_keller switchport trunk encapsulation dot1q switchport mode trunk channel-group 1 mode desirable ! interface GigabitEthernet0/20 description Etherchannel nach sw_w43_keller switchport trunk encapsulation dot1q switchport mode trunk channel-group 1 mode desirable ! interface GigabitEthernet0/21 description Etherchannel nach sw_w43_keller switchport trunk encapsulation dot1q switchport mode trunk channel-group 1 mode desirable ! interface GigabitEthernet0/22 description Etherchannel nach sw_w43_keller switchport trunk encapsulation dot1q switchport mode trunk channel-group 1 mode desirable ! interface GigabitEthernet0/23 ! interface GigabitEthernet0/24 ! interface Vlan1 description Management Vlan zur Konfiguration ip address 192.168.150.109 255.255.255.0 no ip route-cache ! ip default-gateway 192.168.150.200 ip http server logging trap notifications logging 192.168.150.206 snmp-server community cisco RW ! control-plane ! ntp clock-period 36028723 ntp source Vlan1 ntp server 192.168.150.206 end Zitieren Link zu diesem Kommentar
sebastian.f 10 Geschrieben 19. Dezember 2007 Autor Melden Teilen Geschrieben 19. Dezember 2007 Moin, keiner eine Idee? Hat vielleicht schonmal jemand hier ein ähnliches Problem mit einem normalen cisco gehabt also 4500, 2900, 3500? Problem ist derzeit einfach das ich nichtmal weis wo ich anfangen soll... Gruß Zitieren Link zu diesem Kommentar
Nightwalker_z 10 Geschrieben 21. Dezember 2007 Melden Teilen Geschrieben 21. Dezember 2007 Ich kann Dir nur sagen, dass wir ein so ähnliches Szenario bei uns im Einsatz haben und dort funktioniert alles reibungslos. Was passiert mit dem Interface am Switch 1, wenn du das Interface am Switch 2 auf Shutdown setzt? Im Normalbetrieb - welche MAC-Adressen siehst du auf dem Switch1 - Port 1 und welche auf dem Switch2-Port 1? Bei ESX sollten sich die virtuellen Adressen auf die verfügbaren LAN Nics aufteilen, oder? Wie sieht deine virtuelle Switch Konfiguration aus (ESX Seite) ? Zitieren Link zu diesem Kommentar
sebastian.f 10 Geschrieben 21. Dezember 2007 Autor Melden Teilen Geschrieben 21. Dezember 2007 Hallo Nightwalker Am Switch Interface passiert gar nix es ist laut Switch up and running ich kann aber keine MAC Adresse sehen. Im Normalbetrieb verteilen sich die MACs der virtuellen Maschinen und die der Service Console gleichmäßig auf die beiden Interfaces. Wir habe einen virtuellen Switch an dem drei Portgroups auf VMWare Seite angeschlossen sind. (Vmotion, Service Console, SystemNetz f. die VMs). Richtung Switch haben wir 2 Interfaces vmnic0 und vmnic1 die zusammengefasst am Vswitch 1 hängen und physikalisch an jeweils einem Cisco 3020 Switch angeschlossen sind. Wir haben auch schon mit clear mac-address-table die Mac Tabellen auf den Switches gelöscht um zu sehen ob die MAC der Service Console dann am anderen Interface auftaucht aber hat auch nix geholfen. Normalerweise wird doch wenn ein Interface ausfällt vom ESX Server per RARP Protokoll die MAC am andere Interface pupliziert oder? Ich habe irgendwie das Gefühl das das Problem mit den MACs und ARP zusammenhängt... Wie sieht denn deine Config aus, physikalisch und virtuell habt ihr auch ein Bladecenter mit 3020ern ? Danke Gruß Sebastian Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.