Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

packet capture auf dem host mit pktcap-uw

Moderatoren: irix, Dayworker

Member
Beiträge: 88
Registriert: 23.05.2013, 22:14

packet capture auf dem host mit pktcap-uw

Beitragvon vl13 » 06.06.2016, 13:44

Hi,

ich versuche gerade ein problem zu erkunden das mich wirklich ratlos macht.

Eine (einzige) VM kann ploetzlich nur noch systeme im selben layer 2 vlan erreichen.

Was bisher versucht wurde:
1) auf anderen host geschoben => nur Layer2
2) in anderes VLAN geschoben => Layer3 OK
3) ip address im ursrungs vlan geaendert => Layer3 OK
4) anderes netzwerk interface (somit andere MAC) selbes verhalten wie bei 1,2,3


Also auf dem host die port id mittels 'net-stats -l | grep $VM' gemacht und mit dieser ID ein "pktcap-uw --switchport ID -o out.cap"
Das pktcap-uw zeigt mir aber auch bei 3) nur ausgehende pakete an obwohl ich replys in der vm mittels tcpdump sehe

Momentan faellt mir nur noch ein einen span port auf dem upstream switch zu erstellen und den traffic mitzuschneiden

ARP oder doppelte MAC oder bonding / trunking issues kann ich im moment auschliessen, es ist nur diese eine IP betroffen (also auch eine andere VM mit dieser IP und keine NULL route oder ACL vorhanden)

Hat das schon mal jemand gahabt, oder sind jemandem solche issues mit 55u2 build 3568722 bekannt?

Guru
Beiträge: 2731
Registriert: 23.02.2012, 12:26

Re: packet capture auf dem host mit pktcap-uw

Beitragvon ~thc » 06.06.2016, 16:21

vl13 hat geschrieben:Eine (einzige) VM kann ploetzlich nur noch systeme im selben layer 2 vlan erreichen.

Das ist doch genau der gewünschte Effekt eines VLANs: Das man die PCs/VMs logisch auf Layer 2 in getrennte virtuelle Netze einsperrt.

:?:

Member
Beiträge: 88
Registriert: 23.05.2013, 22:14

Beitragvon vl13 » 06.06.2016, 18:23

Aber nur wenn sie nicht ueber ein gateway raus sollen (in diesem fall ein layer3 stack ;)

Hm, denke doch das es ein problem mit den Bridge-Aggregation groups zu tun hat.
Habe gerade die configs von einem altem cisco 3750'er stack angeschaut, hatte damals ein aehnliches problem, die loesung war damals global folgendes zu setzten

Code: Alles auswählen

port-channel load-balance src-dst-ip

In diesem fall ist das ein HP5900AF IRF stack (Comware7) und ich vermute der load-shaing mode link-aggregation load-sharing mode destination-ip source-ip passt nicht.

vSphere Standard Switch:

Code: Alles auswählen

# esxcli network vswitch standard policy failover get -v vSwitch0
   Load Balancing: iphash
   Network Failure Detection: link
   Notify Switches: true
   Failback: true
   Active Adapters: vmnic0, vmnic1, vmnic4, vmnic5
   Standby Adapters:
   Unused Adapters:


Code: Alles auswählen

# display current-configuration interface Bridge-Aggregation
interface Bridge-Aggregation6
 port link-type trunk
 undo port trunk permit vlan 1
 port trunk permit vlan 2 to 4094
 link-aggregation load-sharing mode destination-ip source-ip

# eines der vier interfaces
interface GigabitEthernet1/0/11
 port link-mode bridge
 port link-type trunk
 undo port trunk permit vlan 1
 port trunk permit vlan 2 to 4094
 lldp compliance admin-status cdp txrx
 port link-aggregation group 6

# display link-aggregation verbose
Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing
Port Status: S -- Selected, U -- Unselected,
             I -- Individual, * -- Management port
Flags:  A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,
        D -- Synchronization, E -- Collecting, F -- Distributing,
        G -- Defaulted, H -- Expired

Aggregate Interface: Bridge-Aggregation1
Aggregation Mode: Static
Loadsharing Type: Shar
Management VLAN : None

Aggregate Interface: Bridge-Aggregation6
Aggregation Mode: Static
Loadsharing Type: Shar
Management VLAN : None
  Port             Status  Priority Oper-Key
--------------------------------------------------------------------------------
  GE1/0/11         S       32768    1
  GE1/0/12         S       32768    1
  GE2/0/11         S       32768    1
  GE2/0/12         S       32768    1

Experte
Beiträge: 1362
Registriert: 30.03.2009, 17:13

Beitragvon UrsDerBär » 06.06.2016, 20:02

vl13 hat geschrieben:Aber nur wenn sie nicht ueber ein gateway raus sollen (in diesem fall ein layer3 stack ;)

Na das ist doch Alltag oder? Die Server müssen ja auch mit allen Clients Sprechen können, auch wenn die nicht in der gleichen VLAN sind. Mit VmWare kann man zusammen mit einigermassen gscheiten Switches die Logik komplett von den eigentlichen Server/PC's nehmen.

Member
Beiträge: 88
Registriert: 23.05.2013, 22:14

Beitragvon vl13 » 06.06.2016, 20:34

UrsDerBär hat geschrieben:
vl13 hat geschrieben:Aber nur wenn sie nicht ueber ein gateway raus sollen (in diesem fall ein layer3 stack ;)

Na das ist doch Alltag oder? Die Server müssen ja auch mit allen Clients Sprechen können, auch wenn die nicht in der gleichen VLAN sind. Mit VmWare kann man zusammen mit einigermassen gscheiten Switches die Logik komplett von den eigentlichen Server/PC's nehmen.

Nein, nicht unbedingt, hatte bis vor ein paar Jahren noch ein altes exotisches device das nur L2 konnte, etwas anderes war nicht vorgesehen ... aber was kann man nicht alles mit einer FW, NAT und proxy ARP anstellen/umgehen ;)
Bevor wir aber vom Thema abkommen, hat jemand evtl schon Erfahrungen mit CW7 Link-aggregation und vSwitch Standard ueber mehrere stack members gesammelt?


Zurück zu „vSphere 5.5 / ESXi 5.5“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 15 Gäste