Schlagwort-Archiv: Redundanz

Verbinden von Alcatel und HP 6125G/XG Bladeswitch mit LACP

Die Welt besteht ja nicht nur aus Alcatel, sondern auch aus anderen Herstellern.
So gibt es zum Beispiel auch Bladeswitche in HP Bladecentern, mit denen man uU eine Verbindung eingehen muss bzw will.

Hier beschreibe ich die notwendigen Befehle um ein LACP zwischen einem Alcatel Omniswitch 6450 und einem HP 6125G/XG im IRF Modus zu erstellen.

Auf Alcatel-Seite alles wie gehabt:

lacp linkagg 1 size 2 actor admin key 1 name "To HP Blade" admin state enable
lacp agg 1/25 actor admin key 1
lacp agg 2/25 actor admin key 1
vlan 3000-304 802.1q 1

Auf dem HP Switch sucht man sich die passenden Ports raus (hier TenGig 1/1/1 und 2/1/1) und befreit sie von allen alten Lasten:

system-view
interface ten 1/1/1
default
quit
interface ten 2/1/1
default

Danach legen wir das Aggregat an (heißt hier bridge-aggregation) und machen es zum LACP.

interface bridge-aggregation 10
link-aggregation mode dynamic
quit

Warum es einmal bridge aggregation heiß und dann mit link-aggragation weiterkonfiguriert wird.. HP Logik. Früher hieß das ganze trnk (Für Trunk) es wird also besser.

Danach bringen wir die physischen Interface in das Aggregat;

interface Tengig 1/1/1
port link-aggregation group 10
quit
interface tengig 2/1/1
port link-aggregation group 10
quit

Erst jetzt konfigurieren wir auf dem bridge-Aggregation die VLANs etc.

interface bridge-aggre 10
description "To ALU"
 port link-type trunk
 port trunk permit vlan 1 3000 to 3004

Hält man sich nicht an die Reihenfolge bzw. haben die Interfaces noch Konfiguration kommt es uU zu Fehlern beim konfigurieren:

 port trunk permit vlan 3004    
 Please wait... Done.
 Error: Failed to configure on interface Ten-GigabitEthernet1/1/1!
 Error: Failed to configure on interface Ten-GigabitEthernet2/1/1!

Alcatel Verbinden auf Secondary im Stack

Es kommt schonmal vor, dass man im Stack auch etwas auf der Secondary cmm/Stack-Member machen will.

z.B. schauen wieviel frei ist, bzw. die swlogs anschauen.

SW-Rack > telnet 127.2.2.1
Trying 127.2.2.1...
Connected to 127.2.2.1.
Escape character is '^]'.
login : admin
password :

Welcome to the Alcatel-Lucent OmniSwitch 6450
Software Version 6.6.4.244.R01 Service Release, May 09, 2014.

Copyright(c), 1994-2013 Alcatel-Lucent. All Rights reserved.

OmniSwitch(TM) is a trademark of Alcatel-Lucent registered
in the United States Patent and Trademark Office.

SW-Rack > show running-directory

CONFIGURATION STATUS
Running CMM : PRIMARY,
CMM Mode : DUAL CMMs,
Current CMM Slot : 2,
Running configuration : WORKING,
Certify/Restore Status : CERTIFIED
SYNCHRONIZATION STATUS
Flash Between CMMs : SYNCHRONIZED,
Running Configuration : NOT SYNCHRONIZED,
Stacks Reload On Takeover: ALL NIs (CMM Only Config OUT-OF-SYNC)

SW-Rack >

Auch das swlog kann man sich dann hier einfach anzeigen lassen.

Versucht man das mit den idle units (telnet 127.2.X.1 x= Slotnummer) landet man in der dShell dieser Slots und da will man nicht wirklich hin, wenn man nicht weiß was man tut.

Alcatel-Lucent OS6900 Virtual Chassis aktivieren

Mit dem neuen Firmware Release 7.3.1.632 kann man jetzt 2* 6900er oder 2* OS10k stacken.
Das ganze nennt sich dann Virtual Chassis und funktioniert (erstmal) nur für 2 Chassis.

Im Vergleich zu MC-LAG sollte das eine deutlich einfachere Konfiguration mit sich bringen, da man nur noch ein logisches Gerät hat und z.B. einen LACP agg nur noch da konfiguriert (statt vorher auf beiden Geräten identisch).

Vergleichbar also mit Cisco VSS bei den 6500 (und bald 4500).

Was ist notwendig?
1. eine Advanced Licence (zum testen kann man auch die 5 Tage Lizenz mittels

debug demo-license

einspielen.
Ein paar Zeilen Konfiguration.

Sinnvollerweise macht man sich ein Testverzeichnis und macht die Experimente da drinnen.

mkdir v_chassis
cp /working/* v_chassis

Man braucht natürlich das richtige AOS in dem Verzeichnis (7.3.1.632) und startet dann den Switch mit der 7.3.1.632
reload from v_chassis no rollback-timeout

Auf dem 1.Chassis gibt man als Chassis-ID die eins, auf dem zweiten die 2.
Plant man mehrere solcher Konstrukte sollte man unterschiedliche Gruppen wählen, damit die Split Brain Detection funktioniert (muss man ja bei MC-LAG auch)

Sinnvollerweise vergibt man auch gleich EMP Adressen – darüber wird später eine Split-Brain Detection gemacht, falls der VF-Link mal weg ist. Die Chassis müssen sich also über das EMP Interface gegenseitig erreichen können, eine 1:1 Direktverbindung ist aber nicht sinnvoll/machbar (zumindest nicht wenn man man mehr CMMs z.B. OS10k) verbinden muß.

1.Chassis

virtual-chassis configured-chassis-id 1
virtual-chassis vf-link 0 create
virtual-chassis vf-link 0 member-port 1/1
virtual-chassis chassis-group 2
ip interface emp address 192.168.252.1/24
write memory
convert-configuration to v_chassis

2.Chassis

virtual-chassis configured-chassis-id 2
virtual-chassis chassis-group 2
virtual-chassis vf-link 0 create
virtual-chassis vf-link 0 member-port 1/1
ip interface emp address 192.168.252.2/24
write memory
convert-configuration to v_chassis

Danach startet man beide Chassis mit der neu erstellten Virtual Chassis Konfiguration (siehe vcboot.cfg/vcsetup.cfg im v_chassis Ordner)

Auf beiden Chassis:

reload from v_chassis no rollback-timeout

Nach dem booten sieht man auf dem primären (Master) das andere Chassis Ports des anderen Gerätes und kann wie in einem gewöhnlichen Stack damit hantieren.

 show virtual-chassis topology 
Local Chassis: 1
                                        Config 
 Chas  Role         Status              Chas ID  Pri   Group  MAC-Address      
-----+------------+-------------------+--------+-----+------+------------------
 1     Master       Running             1        100   2      e8:e7:32:XX:XX:69
 2     Slave        Running             2        100   2      e8:e7:32:XX:XX:89

 show chassis 
Local Chassis ID 1 (Master)
  Model Name:                    OS6900-X40,
  Module Type:                   0x5062202,
  Description:                   Chassis,
  Part Number:                   902910-90,
  Hardware Revision:             B08,
  Serial Number:                 M366XXXX,
  Manufacture Date:              Sep 11 2011,
  Admin Status:                  POWER ON,
  Operational Status:            UP,
  Number Of Resets:              29,
  MAC Address:                   e8:e7:32:XX:XX:69

Remote Chassis ID 2 (Slave)
  Model Name:                    OS6900-X40,
  Module Type:                   0x5062202,
  Description:                   Chassis,
  Part Number:                   902910-90,
  Hardware Revision:             B08,
  Serial Number:                 M366XXXX,
  Manufacture Date:              Sep 11 2011,
  Admin Status:                  POWER ON,
  Operational Status:            UP,
  Number Of Resets:              42,
  MAC Address:                   e8:e7:32:XX:XX:89


->show interfaces status 
 Chas/                   DETECTED-VALUES         CONFIGURED-VALUES    
 Slot/    Admin  Auto  Speed   Duplex  Pause   Speed   Duplex  Pause  Link
 Port     Status Nego  (Mbps)                  (Mbps)                 Trap
---------+------+----+--------+------+-------+--------+------+-------+-----
  1/1/1      en   dis   10000   Full     -     10000    Full     -     dis
  1/1/2      en   dis     -      -       -     10000    Full     -     dis
  1/1/3      en   dis     -      -       -     10000    Full     -     dis
 [.. snip ..]
 1/1/40     en   dis     -      -       -     10000    Full     -     dis
  2/1/1      en   dis   10000   Full     -     10000    Full     -     dis
  2/1/2      en   dis     -      -       -     10000    Full     -     dis
 [.. snip ..] 
 2/1/40     en   dis     -      -       -     10000    Full     -     dis

Will man LACPs anlegen geht das „wie immer“:

linkagg lacp agg 1 size 2 admin-state enable name "To_DC" actor admin-key 1 
linkagg lacp agg 2 size 2 admin-state enable name "To_RZ" actor admin-key 2
linkagg lacp port 1/1/31 actor admin-key 1
linkagg lacp port 2/1/31 actor admin-key 1
linkagg lacp port 2/1/39 actor admin-key 2
linkagg lacp port 1/1/39 actor admin-key 2

->show linkagg port 

Chassis/Slot/Port  Aggregate   SNMP Id   Status    Agg  Oper   Link Prim
-------------------+----------+--------+----------+----+-----+-----+----
         1/1/31     Dynamic      1031   ATTACHED      1  UP   UP    YES
         1/1/39     Dynamic      1039   ATTACHED      2  UP   UP    NO 
         2/1/31     Dynamic    101031   ATTACHED      1  UP   UP    NO 
         2/1/39     Dynamic    101039   ATTACHED      2  UP   UP    YES

Fortigate: Zwei WAN Schnittstellen/ISPs nutzen, einen default Weg haben

Möchte man bei einer Fortigate zweit WAN Zugänge oder ISPs anschliessen, z.B. für Backup oder Lastverteilung kommt man zu dem Punkt: Wie geht das?

Szenario:
Einen Provider am WAN1 (schnelle Leitung)
zweiten Provider am WAN2 (langsamere Verbindung)

Wie kann man vorgehen?
Legt man zwei default Routen mit unterschiedlichen Metriken an ist nur die mit der besseren Metrik in der Routingtabelle, d.h. es wird nur die bessere Route genutzt, Verbindungen über die andere Leitung schlägt fehl (RPF wird das wohl verhindern).

Also trägt man zwei default Routen mit gleicher Metrik an!
Jetzt macht die Fortigate standardmäßig ECMP – also Lastverteilung. Beide Leitungen werden genutzt. Leider schert sich die Fortigate nicht um die Bandbreite (ggf kann man da in den aktuellen Versionen mit weightend ECMP was drehen), wird also recht fix die langsamere Leitung überlasten.

Die Lösung: Prioritäten für Routen. Das ist ähnlich wie Metriken, verhindert aber nicht das die Route aus der Routing Tabelle verschwindet. Sind zwei Routen zum Ziel da wird die mit der niedrigeren Priorität gewählt. bei gleicher Prio greift wieder ECMP.
Dadurch die Route in der Routing Tabelle vorhanden ist kann man Sessions über beide WAN Verbindungen aufbauen und mittel Policy Routing auch einzelnen Traffic über eine WAN Strecke forcieren (z.B. http Traffic über die langsamere Verbindung).

Die Prioritäten kann man nur über die CLI einrichten.
Beispiel:

config router static
show

Die entsprechenden Einträge anpassen
edit 1
" set device ""wan1"""
set gateway 192.168.1.100
set priority 1
next
edit 2
" set device ""wan2"""
set priority 5
set gateway 172.16.31.254
next

In diesem Fall würde der Traffic defaultmäßig über WAN1 gehen (niedrigere Priorität), aber eingehender Verkehr über WAN2 wird erlaubt. Fällt WAN1 weg geht der Verkehr über WAN2.

Natürlich muss man sich noch um passende VIPs/ACLs an den entsprechenden Interfaces kümmern und auch DNS im Hinterkopf behalten.

Die ASA von Cisco hat sowas meines Wissens nicht, es gibt immer nur eine aktive Defaultroute Loadbalancing kann sie nicht. Ein Failover kann man ggf mit SLAs.

Cisco Etherchannel konfigurieren (IOS 4506-E)

Zur redundanten Anbindung und zur Erhöhung der Ausfallsicherheit verbindet man Gerät gern mit mehr als einem Kabel sowohl in Ringstrukturen als auch zu einem anderen Gerät. Spanning Tree verhindert dabei Loops. Verbindet man z.B. 2 Core Switche mit mehreren Kabeln kann man auch einer höhere Bandbreite nutzen.

Switch 1:
# conf t
(config)#int port-channel 1
(config-if)#
(config-if) description "Channel zu Core-2"
(config-if) switchport
(config-if) switchport mode trunk
(config-if)exit
(config)#int range te1/1-2
(config-if-range)# description "10gig to Core2
(config-if-range) switchport mode trunk
(config-if-range) channel-group 1 mode desirable
(config-if-range)end

Switch 2 ist analog, also:
# conf t
(config)#int port-channel 1
(config-if)#
(config-if) description "Channel zu Core-2"
(config-if) switchport
(config-if) switchport mode trunk
(config-if)exit
(config)#int range te1/1-2
(config-if-range)# description "10gig to Core2
(config-if-range) switchport mode trunk
(config-if-range) channel-group 1 mode desirable
(config-if-range)end

Verifizieren:
#sh etherchannel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator

M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 1
Number of aggregators: 1
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
1 Po1(SU) PAgP Te1/1(P) Te1/2(P)

Defaultmäßig wird ein anhand von Destination Mac bzw. Destination IP im Load Balancing Algorithmus festgelegt welcher Link im Etherchannel benutzt wird. Das kann bei genutzt das kann aber bei vielen Verbindungen zwischen den selben Systemen zu einer einseitigen Nutzung des Channels kommen. mittels
port-channel load-balance src-dst-port
kann man z.B. Src und Destination Port als Kriterium wählen.

Cisco ASA Firmware Update im Active/Standby Failover Cluster

Firmware auf beide ASAs kopieren, ggf passendes asdm auf die ASA bringen.

Diese beim nächsten Start benutzen
boot system disk0:/asa804-k8.bin
asdm image disk0:/asdm-61551.bin

Abspeichern nicht vergessen !!!:
wr mem

ACHTUNG: die firmwares werden nicht auf die standby Unit gesynct, die Konfiguration schon.. daher müssen die Firmwares auf beide ASAs kopiert werden. einfach geht das per ASDM einmal auf die aktiv einmal auf die passive IP und dann hochladen per Browser alternativ tftp o.ä.

wir vergewissern uns das wir auf der activen ASA sind:

ASA# sh failov state
State Last Failure Reason Date/Time
This host - Primary
Active None
Other host - Secondary
Standby Ready None
====Configuration State===
Sync Done - STANDBY
====Communication State===
Mac set

This host Primary Active.. gut!

Wir starten die stanby unit neu:
failover reload-standby
warten bis die Replikation der Konfig abgeschlossen ist (mit sh failover state vergewissern das die andere standby ready ist) und geben die Active Rolle im Cluster an die neugebootete Kiste ab:
no failover active

Dann starten wir die, jetzt im Standby laufende, Maschine (noch alte Firmware) neu indem wir uns wieder auf die aktive ASA verbinden und dann wieder
failover reload-standby
eingeben.

Generell ist es aber egal welche Maschine gerade aktiv ist, daher braucht man danach nicht wieder zurückzuschwenken (außer man will das immer die aktive ASA in Rack X steht)