Gruppen-Mitgliedschaft unter AIX mit chgrpmem verwalten

AIX bietet ein elegantes Kommando um die Mitgliedschaft von Benutzern in Gruppen zu ändern: chgrpmem.

Als Beispiel verwenden wir die Benutzer user01, user02, …, sowie die Gruppe mygroup:

$ lsgroup mygroup
mygroup id=225 admin=false users= registry=files
$

Die Gruppe mygroup besitzt aktuell noch keine Mitglieder (users=““).

Um die beiden lokalen Benutzer user01 und user02 der Gruppe mygroup hinzuzufügen, muss die Option „-m“ (Member) verwendet werden. Dann folgt das Zeichen Plus „+“ für Hinzufügen und eine komma-separierte Liste von Benutzernamen. Als letztes Argument muss noch die Gruppe angegeben werden:

# chgrpmem -m + user01,user02 mygroup
#
# lsgroup mygroup
mygroup id=225 admin=false users=user01,user02 registry=files
#

Verwendet man anstelle des Plus-Zeichens „+“ das Gleichheits-Zeichen „=“, dann wird die aktuelle Liste der Benutzer durch die angegebene Liste von Benutzernamen überschrieben:

# chgrpmem -m = user03,user04,user05 mygroup
# 
# lsgroup mygroup
mygroup id=225 admin=false users=user03,user04,user05 registry=files
#

Das Entfernen von Benutzern erfolgt durch Verwenden eines Minus-Zeichens „“ z.B. Entfernen des Benutzers user04:

# chgrpmem -m - user04 mygroup
# 
# lsgroup mygroup
mygroup id=225 admin=false users=user03,user05 registry=files
#

Das Entfernen eines Benutzers aus der Mitgliederliste einer Gruppe muss aber nicht immer erfolgreich sein! Wir legen den Benutzer user06 mit primärer Gruppe mygroup an:

# mkuser pgrp=mygroup user06
# 
# lsgroup mygroup
mygroup id=225 admin=false users=user03,user05,user06 registry=files
#

Die Ausgabe von lsgroup zeigt das der Benutzer user06 ebenfalls Mitglied der Gruppe mygroup ist. Allerdings lässt sich in diesem Fall die Mitgliedschaft nicht aufheben:

# chgrpmem -m - user06 mygroup
Cannot drop "user06" from primary group "mygroup".
#

Ein Benutzer muss immer eine primäre Gruppe haben! Mit dem Kommando chgrpmem können nur die zusätzlichen Mitgliedschaften von Benutzern verwaltet werden. Die primäre Gruppe kann nur mit dem Kommando chuser geändert werden.

Hinweis: Mit dem Kommando chgrpmem und der Option „-a“ können auch die Administratoren einer Gruppe geändert werden. Dies wird in der Praxis aber eher selten verwendet und ist daher hier auch nicht angesprochen.

Ändern der PVID eines Physical Volumes

Jedes Physical Volume das vom AIX LVM verwendet wird, besitzt eine eindeutige Physical Volume ID, kurz PVID. Die PVID ist eine Software-generierte ID, die im Header Bereich einer Platte (Block 0) abgespeichert wird. Wenn eine neue Platte einem AIX System hinzugefügt wird, dann besitzt das neue Physical Volume noch keine PVID. Sobald ein Physical Volume einer Volume Group hinzugefügt wird, wird eine PVID generiert, wenn das Physical Volume noch keine PVID haben sollte. Eine schon existierende PVID wird übernommen.

Eine PVID kann auch manuell mit Hilfe des Kommandos chdev erzeugt werden. Dabei wird das Attribut pv auf den Wert yes gesetzt:

# chdev -l hdisk3 -a pv=yes
hdisk3 changed
#

Die gesetzte PVID kann entweder mit dem Kommando lsattr oder auch einfach mit lspv angezeigt werden:

$ lsattr -El hdisk3 -a pvid -F value
00c276b0084049750000000000000000
$
$ lspv |grep hdisk3
hdisk3          00c276b008404975                    None                       
$

Eine PVID kann auch wieder entfernt werden. Dazu darf das Physical Volume allerdings nicht in Verwendung sein (.z.B. als Teil einer Volume Group).

Um eine PVID eines Physical Volumes zu löschen, kann das Attribut pv auf den Wert clear gesetzt werden:

# chdev -l hdisk3 -a pv=clear
hdisk3 changed
#

Die PVID wurde entfernt, wie die nachfolgenden Aussagen zeigen:

$ lsattr -El hdisk3 -a pvid -F value
none
$
$ lspv |grep hdisk3
hdisk3          none                                None                       
$

Der Versuch die PVID eines Physical Volumes zu löschen, das in Verwendung ist, führt zu der folgenden Fehlermeldung:

# chdev -l hdisk0 -a pv=clear
Method error (/usr/lib/methods/chgdisk):
        0514-062 Cannot perform the requested function because the
                 specified device is busy.
     pv    

#

 

Größe eines Physical Volumes bestimmen

Um die Größe eines Physical Volumes (Disk, LUN) zu bestimmen, gibt es unter AIX eine Reihe verschiedener Möglichkeiten.

Besitzt man root-Rechte, kann das Kommando bootinfo mit der Option „-s“ (size) verwendet werden:

#  bootinfo -s hdisk0
51200
#

Die Größe des Physical Volumes wird in MB ausgegeben. Im Beispiel also 51.200 MB oder ca 50 GB.

Ohne root-Rechte, kann das Kommando getconf verwendet werden. Mit diesem Kommando können systemweite Konfigurationsparameter, aber auch gerätespezifische Variablen angezeigt werden. Um die Größe eines Physical Volumes anzuzeigen, kann die gerätespezifische Variable DISK_SIZE verwendet werden. Das in Frage kommende Physical Volume wird über den absoluten Pfad der Block- oder Character-Gerätedatei des Physical Volumes angegeben:

$ getconf DISK_SIZE /dev/hdisk0
51200
$

Auch hier wird die Größe in MB ausgegeben.

Eine weitere Möglichkeit, die aber wieder root-Rechte erfordert, ist die Verwendung des Kommandos lsmpio. Dieses bietet über die Option „-q“ (query) Daten über ein MPIO Storage Gerät anzuzeigen:

# lsmpio -ql hdisk0
Device:  hdisk0
…
           Capacity:  50.00GiB
…
#

Die Größe wird dieses Mal direkt in GB (GiB) angezeigt.

Ist das Physical Volume Teil einer Volume Group, kann auch das Kommando lspv verwendet werden, um die Größe zumindest abzuschätzen:

$ lspv hdisk0
…
TOTAL PPs:          199 (50944 megabytes)    VG DESCRIPTORS:   2
…                                      
$

Hier wird der für Daten verwendbare Bereich angegeben (50.944 MB), das Physical Volume selbst ist etwas größer, da ja auch noch Platz für Verwaltungsinformationen verwendet wird.

LPAR-Tool 1.7.0.1 ist ab sofort verfügbar

Ab sofort ist die Version 1.7.0.1 des LPAR-Tools in unserem Download-Bereich verfügbar.

Die neue Version unterstützt unter anderem die folgenden neuen Features:

    • Installation von IFixes und Updates auf der HMC (hmc help updhmc)
    • System-Firmware Updates (und mehr) von Managed Systems (ms help updatelic)
    • Anzeigen von FLRT Daten mit Online Abfrage bei IBM (hmc help flrt, ms help flrt, lpar help flrt)
    • Konfiguration von NTP auf HMCs (hmc help ntp)

Es stehen Versionen für Linux, AIX und Macos zur Verfügung.

Alle Versionen beinhalten eine Test-Lizenz mit einer Gültigkeit bis 30.09.2022.

Also Downloaden, Installieren und dann Ausprobieren!

show_life_cycle: neuer URL für FLRT Lite Daten-File

IBM hat den URL für das FLRT Lite Daten-File geändert. Über die alte URL:

 https://www14.software.ibm.com/support/customercare/flrt/liteTable

kann das Daten-File nicht mehr bezogen werden. Die neue URL ist:

https://esupport.ibm.com/customercare/flrt/liteTable

Für Nutzer unseres Skripts show_life_cycle haben wir die aktualisierte Version des Skripts mit dem neuen URL in unserem Download-Bereich zur Verfügung gestellt.

(Vielen Dank an Lutz Leonhardt für den Hinweis.)

Welche Größe hat der interne Log bei JFS2

inline log size

Eine triviale Frage über die wir kürzlich gestolpert sind:

Wie groß ist denn der interne JFS2 Log aktuell?

Die Größe des internen JFS2 Logs muss die folgenden beiden Bedingungen erfüllen:

    1. Der Log kann nicht größer als 10% der Dateisystem-Größe sein.
    2. Die maximale Größe kann 2047 MB nicht überschreiten.

Beim Anlegen eines JFS2 Dateisystems mit internem Log, wenn keine Log-Größe (-a logsize=Value) angegeben wird, werden standardmäßig 0.4% der Dateisystem-Größe verwendet. Der Wert 0.4% ist in der Manual Page zu crfs dokumentiert.

Aber, wie groß ist denn der interne JFS2 Log gerade?

Diese Information liefert das Kommando dumpfs. Es erwartet als Argument entweder den Mount-Punkt eines JFS2 Dateisystems oder die Geräte-Datei des unterliegenden Logical Volumes. Das Kommando listet den Superblock, sowie eine Reihe weiterer Verwaltungs-Informationen auf. Die Ausgabe kann bei größeren Dateisystemen sehr lang sein. Da wir nur an dem JFS2 Log interessiert sind, empfiehlt es sich die Ausgabe durch das Kommando grep zu filtern:

# dumpfs /data | grep -i log
aggregate block size    4096            log2 of aggregate block size    12
LVM I/O Transfer size   512             log2 of LVM transfer  size      9
log2 of block size/transfer size        3
Aggregate attributes    J2_GROUPCOMMIT J2_INLINELOG
log device      0x8000002700000001 log serial number    0x26
Inline Log: 541065216 (132096); 1024
fsck Service Log number of blocks: 50
Extendfs Inline Log Working Space: 541065216 (132096); 1024
#

Der letzte Wert in der Zeile „Inline Log:“ gibt die Größe des internen Logs in Blöcken an. Die Blockgröße des Dateisystems findet man in der Zeile „aggregate block size“. In unserem Falle hat der interne Log eine Größe von 1024 Blöcken, zu jeweils 4096 Bytes. Dies ergibt eine Größe von 4 MB (1024 * 4 KB).

Für den Fall das ein externer Log verwendet wird, sieht die Ausgabe wie folgt aus:

# dumpfs / | grep -i log
aggregate block size    4096            log2 of aggregate block size    12
LVM I/O Transfer size   512             log2 of LVM transfer  size      9
log2 of block size/transfer size        3
log device      0x8000000a00000003 log serial number    0xb
Inline Log: 0 (0); 0
fsck Service Log number of blocks: 50
Extendfs Inline Log Working Space: 0 (0); 0
#

Der interne Log hat die Größe 0 Blöcke.

Allerdings ist dies nicht die einfachste Möglichkeit. Chris Gibson weist auf die Option „-q“ des Kommando lsfs hin, welche für JFS und JFS2 Dateisysteme zusätzliche Informationen anzeigt:

# lsfs -q /filesystem
Name            Nodename   Mount Pt               VFS   Size    Options    Auto Accounting
/dev/fslv01     --         /filesystem            jfs2  1048576 --         no   no
  (lv size: 1048576, fs size: 1048576, block size: 4096, sparse files: yes, inline log: yes, inline log size: 4, EAformat: v1, Quota: no, DMAPI: no, VIX: yes, EFS: no, ISNAPSHOT: no, MAXEXT: 0, MountGuard: no)
#

Die Größe des Inline Logs wird dort direkt in MB angegeben (inline log size: 4).

Die Größe des internen JFS2 Log festzustellen ist also mit dem richtigen Kommando (dumpfs lsfs) kein Problem!

IOS-Version als normaler Benutzer anzeigen

Auf einem Virtual-I/O-Server kann man die IOS-Version als Benutzer padmin mit Hilfe des Kommandos ioslevel anzeigen:

padmin> ioslevel
3.1.2.10
padmin>

Als Benutzer root (nach Verwendung von oem_setup_env), lässt sich die IOS-Version wie folgt anzeigen:

# /usr/ios/cli/ioscli ioslevel
3.1.2.10
#

Beide Kommandos funktionieren aber nicht als normaler, nicht privilegierter, Benutzer:

$ ioslevel
ksh: ioslevel: not found.
$ /usr/ios/cli/ioscli ioslevel
Access to run command is not valid.

$

Die IOS-Version ist aber einfach in einer Text-Datei gespeichert und lässt sich als normaler Benutzer ganz einfach mit dem Kommando cat anzeigen:

$ cat /usr/ios/cli/ios.level
3.1.2.10
$

YUM mit NIMHTTP

Ab AIX 7.2 unterstützt NIM die Verwendung von  HTTP. Hierzu gibt es den neuen NIM-Service Handler nimhttp (Port 4901). Dies bietet die Möglichkeit YUM Repositories auf einem NIM-Server mit Hilfe dieses NIM-Service Handlers zur Verfügung zu stellen. Die Repositories müssen hierzu unterhalb des Document-Root (standardmäßig /export/nim) abgespeichert werden. Der Zugriff von einem AIX-Client aus kann dann über HTTP erfolgen.

Die Repositories müssen dazu auf dem AIX-Client unter /opt/freeware/etc/yum/yum.conf oder /opt/freeware/etc/yum/repos.d konfiguriert werden. Alle verfügbaren YUM Operationen werden auf diesem Wege unterstützt.

Wird auf dem NIM-Server ohnehin nimhttp genutzt, entsteht hierdurch kein zusätzlicher Aufwand.

Im Folgenden ist die Konfiguration für die Verwendung von YUM mit nimhttp gezeigt.

Voraussetzung ist zunächst das der NIM-Service Handler nimhttp auf dem NIM-Server aktiv ist:

aixnim # lssrc -s nimhttp
Subsystem         Group            PID          Status
 nimhttp                           19136996     active
aixnim #

Sollte nimhttp noch nicht aktiviert worden sein, kann dies im einfachsten Fall mit Hilfe des Kommandos nimconfig auf dem NIM-Server nachgeholt werden:

aixnim # nimconfig -h
0513-077 Subsystem has been changed.
0513-059 The nimhttp Subsystem has been started. Subsystem PID is 19136996.
aixnim #

Hinweis: Die Konfiguration von nimhttp wird an anderer Stelle gezeigt.

Für Testzwecke legen wir unter /export/nim (Document-Root) eine kleine Text-Datei auf dem NIM-Server an:

aixnim # echo "testfile for nimhttp" >/export/nim/testfile
aixnim #

Als nächstes überprüfen wir auf dem NIM-Client die Funktionalität indem wir mit dem NIM-Client Kommando nimhttp die angelegte Test-Datei vom NIM-Server herunterladen:

aix01 # nimhttp -f testfile -o dest=/tmp -v
nimhttp: (source)       testfile
nimhttp: (dest_dir)     /tmp
nimhttp: (verbose)      debug
nimhttp: (master_ip)    aixnim
nimhttp: (master_port)  4901

sending to master...
size= 46
pull_request= "GET /testfile HTTP/1.1
Connection: close

"
Writing 21 bytes of data to /tmp/testfile
Total size of datalen is 21. Content_length size is 21.
aix01 #

(Die Option ‚-v‘ sorgt für den gezeigten Debugging-Output.)

Die Testdatei wurde unter /tmp/testfile abgespeichert.

Ein weiterer Test mit dem Kommando curl (verfügbar über die AIX-Toolbox) zeigt ebenfalls das nimhttp erfolgreich für den Download von Daten verwendet werden kann:

aix01 # curl http://aixnim:4901/testfile
testfile for nimhttp
aix01 #

Die Verwendung von nimhttp für den Zugriff auf YUM-Repositories sollte also prinzipiell möglich sein.

Wir haben Kopien der von IBM bereitgestellten Repositories der AIX-Toolbox auf unserem NIM-Server in den folgenden Verzeichnissen abgelegt:

/export/nim/aixtoolbox/RPMS/noarch          AIX_Toolbox_noach (AIX noarch repository)

/export/nim/aixtoolbox/RPMS/ppc               AIX_Toolbox (AIX generic repository)

/export/nim/aixtoolbox/RPMS/ppc-7.1         AIX_Toolbox_71 (AIX 7.1 specific repository)

/export/nim/aixtoolbox/RPMS/ppc-7.2         AIX_Toolbox_72 (AIX 7.2 specific repository)

Damit ein AIX Client System auf diese Repositories zugreifen kann, müssen diese in der YUM Konfiguration hinterlegt sein. Wir haben der Einfachheit halber die Repositories in die Konfigurations-Datei /opt/freeware/etc/yum/yum.conf eingetragen:

aix01 # vi /opt/freeware/etc/yum/yum.conf
[main]
cachedir=/var/cache/yum
keepcache=1
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1

[AIX_Toolbox]
name=AIX generic repository
baseurl=http://aixnim:4901/aixtoolbox/RPMS/ppc/
enabled=1
gpgcheck=0

[AIX_Toolbox_noarch]
name=AIX noarch repository
baseurl=http://aixnim:4901/aixtoolbox/RPMS/noarch/
enabled=1
gpgcheck=0

[AIX_Toolbox_72]
name=AIX 7.2 specific repository
baseurl=http://aixnim:4901/aixtoolbox/RPMS/ppc-7.2/
enabled=1
gpgcheck=0

aix01 #

Alternativ kann für jede Repository auch ein eigenes repoid-File unter /opt/freeware/etc/yum/repos.d angelegt werden.

Der entscheidende Eintrag ist jeweils das Attribut baseurl. Hier wird als URL http verwendet. Dem Hostnamen des NIM-Servers wird mit Doppelpunkt getrennt die Port-Nummer von nimhttp (Port 4901) mitgegeben. Der Pfad ist dann relativ zu /export/nim (Document-Root) auf dem NIM-Server.

Ein Auflisten der verfügbaren YUM-Repositories mit dem Kommando yum zeigt die erwarteten Repositories:

aix01 # yum repolist
repo id                                     repo name                                             status
AIX_Toolbox                                 AIX generic repository                                2740
AIX_Toolbox_72                              AIX 7.2 specific repository                            417
AIX_Toolbox_noarch                          AIX noarch repository                                  301
repolist: 3458
aix01 #

Um zu demonstrieren das auch das Installieren von RPMs auf diesem Wege mit nimhttp möglich ist, zeigen wir die Installation von wget:

aix01 # yum install wget
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package wget.ppc 0:1.21.1-1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

========================================================================================================
Package              Arch                Version                     Repository                   Size
========================================================================================================
Installing:
wget                 ppc                 1.21.1-1                    AIX_Toolbox                 703 k

Transaction Summary
========================================================================================================
Install       1 Package

Total size: 703 k
Installed size: 1.4 M
Is this ok [y/N]: y
Downloading Packages:
Running Transaction Check
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : wget-1.21.1-1.ppc                                                                    1/1
From wget-1.21.1 onwards, symbolic link of wget in /usr/bin is removed.
The binary is shipped in /opt/freeware/bin. Please use absolute path or
add /opt/freeware/bin in PATH environment variable to use the binary.

Installed:
  wget.ppc 0:1.21.1-1                                                                                  

Complete!

aix01 #

Das AIX-System muss nicht zwingend ein NIM-Client sein, da YUM nicht auf NIM zurückgreift. YUM verwendet lediglich den vom NIM-Master bereitgestellten http-Server. Die AIX-Version spielt ebenfalls keine Rolle, der AIX-Client kann unter AIX 7.1 oder AIX 7.2 laufen.

Hinweis: Für AIX 7.3 wird anstelle von YUM der Dandified YUM (DNF) verwendet.

Virtual Network Interface Controller (vNIC)

vNIC adapter with 2 vNIC backing devices and vNIC failover.

Der große Nachteil von SR-IOV, sowie oben beschrieben, besteht darin, das das Verschieben (LPM) von LPARs mit logischen SR-IOV Ports nicht möglich ist. Nach der Einführung von SR-IOV auf Power Systemen gab es eine Reihe von Vorschlägen für Workarounds. Allerdings bedingen alle diese Workarounds zum Einen eine besondere Konfiguration und zum Anderen eine Reihe von Umkonfigurationen die vor und nach einer LPM-Operation durchzuführen sind. Im praktischen Alltag werden dadurch LPM-Operationen aber unnötig verkompliziert.

Mit der Einführung von vNICs können Client-LPARs SR-IOV Adapter benutzen und trotzdem LPM unterstützen. Wie schon bei VSCSI und VFC wird dazu ein Paar von Adaptern benutzt: auf der Client-LPAR wird der sogenannte vNIC Adapter in einem virtuellen Slot verwendet und auf einem Virtual-I/O-Server wird ein zugehöriger vNIC-Server Adapter verwendet. Der logische SR-IOV Port wird dem Virtual-I/O-Server zugeordnet. Der vNIC-Server Adapter, auch als vNIC-Backing-Device bezeichnet, dient dabei als Proxy für den logischen SR-IOV Port. Das Zusammenspiel der verschiedenen Adapter ist in Bild 7.19 dargestellt.

Communication path of vNIC for control information and data.
Bild 7.19: Kommunikationspfad von vNIC für Kontroll-Informationen und Daten.

Um eine gute Performance zu erreichen, werden nur Kontroll-Informationen vom vNIC Adapter der Client-Adapter zum vNIC Server Adapter übertragen, welche von diesem über den zugehörigen logischen SR-IOV Port zum entsprechenden logischen Port (Virtual Function) des SR-IOV Adapters übertragen werden. Die Daten selbst werden zwischen vNIC Client-Adapter und dem logischen Port des SR-IOV Adapters per DMA (Direct Memory Access) mit Hilfe des Hypervisors übertragen. Es findet also insbesondere kein Kopieren der Daten über den Virtual-I/O-Server statt. Der vNIC Adapter auf dem Client ist ein rein virtueller Adapter, daher funktioniert LPM auch problemlos. Der Client besitzt den logischen SR-IOV Port nicht und greift auch nicht selbst über den PCIe Bus (Switch) auf diesen zu.

Shared Ethernet Adapter

SEA with multiple trunking adapters and VLANs

Trotz SR-IOV und vNIC ist Shared Ethernet immer noch die am häufigsten verwendete Virtualisierungslösung, wenn es um die Virtualisierung von Ethernet geht. Dabei implementiert der POWER Hypervisor virtuelle interne IEEE802.1q kompatible Netzwerk-Switches, die im Zusammenspiel mit sogenannten Shared Ethernet Adaptern oder kurz SEA die Anbindung an externe Netzwerke übernehmen. Die Shared Ethernet Adapter werden durch den Virtual-I/O-Server in Software als Layer-2 Bridge implementiert.

Wie in Bild 8.2 gezeigt, kann ein Shared Ethernet Adapter mehrere sogenannte Trunking Adapter besitzen. Der gezeigte SEA hat die 3 Trunking Adapter ent8, ent9 und ent10, welche alle 3 an den virtuellen Switch mit dem Namen ETHMGMT angebunden sind. Alle Trunking Adapter unterstützen im gezeigten Fall VLAN-Tagging. Neben den Port-VLAN-IDs (PVIDs) besitzen die 3 Trunking Adapter noch weitere VLANs über VLAN-Tagging. Neben der Anbindung an den virtuellen Switch über die Trunking Adapter besitzt der SEA noch eine Anbindung an ein externes Netzwerk über den physikalischen Netzwerk-Adapter (ent0). Netzwerk-Pakete von Client-LPARs an externe Systeme werden über einen der Trunking-Adapter zum SEA und dann über den zugehörigen physikalischen Netzwerk-Adapter ins externe Netzwerk weitergeleitet. Netzwerk-Pakete von externen Systemen an Client-LPARs werden vom SEA über den Trunking Adapter mit dem richtigen VLAN an den virtuellen Switch weitergeleitet, welcher die Pakete dann an die Client-LPAR weiterleitet.

SEA with multiple trunking adapters and VLANs
Bild 8.2: SEA mit mehreren Trunking Adaptern und VLANs.

Im einfachsten Fall kann ein SEA aus nur einem Trunking Adapter bestehen. Ein SEA kann bis zu 16 Trunking Adaptern besitzen, wobei jeder der Trunking-Adapter neben der Port-VLAN-ID bis zu 20 weitere VLANs besitzen kann.

Welche SEAs es auf einem Virtual-I/O-Server schon gibt, lässt sich mit Hilfe des Kommandos „vios lssea“ (list SEAs) herausfinden:

$ vios lssea ms05-vio1
                                       TIMES   TIMES    TIMES    BRIDGE 
NAME   HA_MODE  PRIORITY  STATE       PRIMARY  BACKUP  FLIPFLOP  MODE
ent33  Sharing  1         PRIMARY_SH  1        1       0         Partial
ent34  Sharing  1         PRIMARY_SH  1        1       0         Partial
$

Zu jedem SEA werden einige grundlegende Informationen angezeigt, wie z.B. der HA-Mode (siehe später), die Priorität des SEA, sowie Informationen wie häufig der SEA schon Primary bzw. Backup war.