Cisco Autonomous AP Image filename

Gerade in der Release note entdeckt was die kryptischen Dateinamen der Autonomous AP Images zu bedeuten haben.

Cisco AP Autonomous Image

Des Weiteren kann man anhand des Dateinamen auch rauslesen, ob es sich um ein Autonomous, Lightweight oder Recovery Image handelt. Darüber Auskunft gibt die Zahl hinter dem „w“, zB.:

ap1g1-k9w7-tar.153-3.JC.tar

 

k9w7 – autonomous IOS
k9w8 – full lightweight IOS
rcvk9w8 – lightweight recovery image

 

Cisco Prime Infrastructure Upgrade Path 2.0.x to 3.0.x

Bei einem Kunden eine ältere Prime Infrastructure Version 2.0.x am laufen, die nun auf Version 3.0 upgraded werden soll. 

Es ist leider nicht möglich ein direktes Upgrade von Prime Infrastructure 2.0.x auf 3.0.x durchzuführen, mehre Schritte sind notwendig. Nebst inline Upgrade von Zwischenversionen, ist es auch notwendig teils eine neue VM, ab .OVA hochzuziehen und ein Backup export + Backup Import vorzunehmen.

Nachfolgend eine Übersicht der Steps:

Ausgangsversion:

prime/admin# show ver
Version information of installed applications
———————————————
Cisco Prime Infrastructure
——————————————
Version : 2.0.0.0.294-2
 
Schauen wir uns die Requirements der jeweiligen Upgrade Notes der Reihe nach rückwärts an:
 

If You Are Upgrading From Previous Releases of Prime Infrastructure

You can upgrade the following Prime Infrastructure versions to Prime Infrastructure 3.0:

  • Cisco Prime Infrastructure 2.2.3
  • Cisco Prime Infrastructure 2.2.2
  • Data Center Technology Package 1.0.0 for Cisco Prime Infrastructure 2.2.1
  • Wireless Technology Package 1.0.0 for Cisco Prime Infrastructure 2.2.1
  • Cisco Prime Infrastructure 2.2.1
  • Cisco Prime Infrastructure 2.2

If your product/version is not in this list, to upgrade to 3.0, you must first upgrade to version 2.2.x at a minimum.

 

Upgrade Guide 2.2.x

If You Are Upgrading From Previous Releases of Prime Infrastructure

This version of Prime Infrastructure does not offer an in-place upgrade. To upgrade to the latest version, you must instead install this version of Prime Infrastructure as a virtual appliance on a fresh server, or order it pre-installed on a fresh physical appliance. You can then migrate your data from your old Prime Infrastructure installation to the new one, using an application backup from the previous installation.
If you are currently using one of the following versions of Prime Infrastructure, you can back up your existing data and then restore that data to a different server running Prime Infrastructure 2.2:
  • Cisco Prime Infrastructure 2.1.2 (with the UBF patch)
  • Cisco Prime Infrastructure 2.1.1 (with the UBF patch)
  • Cisco Prime Infrastructure 2.1.0.0.87
  • Cisco Prime Infrastructure 1.4.2
  • Cisco Prime Infrastructure 1.4.1
  • Cisco Prime Infrastructure 1.4.0.45

Upgrade 2.1.0.0.87

 
Upgrading Cisco Prime Infrastructure

You can upgrade the following Cisco Prime Infrastructure (and predecessor) products to Cisco Prime Infrastructure 2.1:
Cisco Prime Infrastructure 2.0.0.0.294
Cisco Prime Infrastructure 1.3.0.20

If you are using a version earlier than 1.3.0.20, see the instructions for upgrading your software to version 2.0 provided in the Cisco Prime Infrastructure 2.0 Quick Start Guide . There is no upgrade path from version 1.4.x to version 2.1 at present.

Before attempting to upgrade to 2.1, make sure that you download the appropriate patch listed in Table 7 . and then install it using the instructions in Installing Patches . Once you have installed the appropriate patches, you will also need to take a new application backup before performing a system migration or inline upgrade.
 
 
 
Der gesamte Upgrade Path lautet somit:  
2.0.0.294 -> 2.1.0.0.87 -> 2.2.0.158 -> 3.0.0.0.78 
 
 
 
Cisco Prime Upgrade 2.0.0.294 to 2.1.0.0.87
Cisco Prime Upgrade 2.0.0.294 to 2.1.0.0.87
Cisco Prime Infrastructure 2.1.0.0.87  to 2.2.0.158
Cisco Prime Infrastructure 2.1.0.0.87 to 2.2.0.158
Cisco Prime Infrastructure 2.2.0.158  to 3.0.0.0.78
Cisco Prime Infrastructure 2.2.0.158 to 3.0.0.0.78
Cisco Prime Infrastructure 2.2.0.158  to 3.0.0.0.78 Alternativ
Cisco Prime Infrastructure 2.2.0.158 to 3.0.0.0.78 Alternativ

 

 

Für alle weiteren Fragen kann ich folgendes Dokument empfehlen:

http://www.cisco.com/c/dam/en/us/products/collateral/cloud-systems-management/prime-infrastructure/presentation-c97-735996.pdf

Sophos Firewall rules per IPTables auf der Console deaktivieren

Hier eine kurze Beschreibung wie man sämtliche Firewall Rules auf einer Sophos per Console aushebeln kann ohne sie permanent zu löschen.

Wann ist das nützlich?

  • Wenn eine Fehlerhafte ACL Konfiguriert wurde, die Zugriff sperrt.
  • Wenn man sich vom Webadmin ausgeschlossen hat, weil man nicht unter Allowed Networks gelistet ist.

Symptome:

Nach einer Anpassung der Konfiguration ignoriert die Firewall jede Verbindung auf IP Ebene. Ports gehen ca alle 30 Sekunden kurz down. Einziges Lebenszeichen aus Netzwerk Sicht sind antworten auf ARP Requests.

 

Ursache (Hypothese):

Der Config Prozess, der die Einstellungen von der Datenbank auf die Firewall überträgt, stürzt während der Verarbeitung ab. Da die iptables Firewall standardmässig auf DROP steht werden die Ports für SSH, Webinterface und auch ICMP nicht mehr freigegeben. Die Firewall schottet sich sozusagen selbst ab.

 

Lösungen:

Wenn kein Backup vorhanden ist und der SSH Zugriff aktiviert worden ist kann man sich über einen Monitor & Tastatur direkt an der Firewall mit dem user root und dem admin Passwort einloggen. Mit dem Befehl

„iptables –I INPUT 1 –j ACCEPT“

fügt man eine neue Regel an erster Stelle für eingehende Pakete ein welche pauschal alles erlaubt.

Da die Firewall nach kurzer Zeit bemerkt das der Konfigurations-Prozess nicht mehr läuft startet sie den Prozess immer wieder neu und löscht damit auch die manuell eingefügten Regeln. Daher muss der iptables Befehl mit dem watch Befehl kombiniert werden, dieser führt den Prozess alles 2 Sekunden aus:

watch iptables –I INPUT 1 –j ACCEPT

der Prozess kann mit CTRL+C wieder beendet werden. Der Zugriff auf das Webinterface funktioniert jetzt wieder eingeschränkt, da die Verbindung regelmässig abbricht (wegen Config Neustart) können keine längeren Anfragen ausgeführt werden, zudem funktioniert auch das Einspielen eines Backups nicht. Es ist daher sinnvoll nur die Änderung vor dem Crash rückgängig zu machen und dann zu testen ob die Firewall wieder läuft.

Sophos SMS Gateway Funktion

Die SMS Funktion wurde bei Sophos auf Basis eines Feature Request in der Version 9.2.x irgendwann man eingeführt, verschwand dann allerdings wieder aus dem GUI. Zweischenzeitlich war recht unklar, wann und wie die Funktion eingeführt wird.

Der Feature Request ist hier zu finden:

Wireless: SMS Passcode for HotSpot

Folgender Kommentar eines Sophos Admins verschafft Klarheit was es mit der halbwegs- Einführung aufsich hat:

Aktuell ist unser Produkt-Management noch dran eine Entscheidung zu treffen welche SMS-Provider zum finalen Release des Features unterstützen. Daher wurde das Feature (welches bereits fertig entwickelt wurde und funktioniert) vorerst im Webadmin versteckt. Während der Entwicklungsphase haben die Entwickler sich 5 internationale Provider rausgesucht um die Funktion des Features zu testen. Diese 5 Provider können aktuell gewählt und genutzt werden. Der Kunde hat also jetzt die Möglichkeit das Feature via Kommandozeile zu aktivieren und dann schlussendlich zu nutzen, jedoch mit dem Hinweis dass es sein KÖNNTE (aber nicht muss), dass ein oder mehrere dieser aktuellen 5 Provider nicht mehr auf der finalen SMS-Provider Liste steht/stehen und er dann ggfs. den Anbieter wechseln MÜSSTE. Wie gesagt wurde das aktuell noch nicht entschieden. Einer der 5 Provider ist „SMSTrade“ und damit ein deutscher SMS Provider. Mit diesem haben wir vom Presales bereits schon erfolgreich getestet und SMS-Authentifizierungen am Hotspot durchgeführt. Hierbei kann man via Prepaid auch für z.B. 20 Euro sich ein SMS-Paket von rund 800 SMS kaufen und somit ohne Vertragslaufzeit immer wieder nachkaufen.
 
Zum aktivieren via Kommandozeile müssen folgender Befehl abgesetzt werden:
 
touch /var/sec/chroot-httpd/tmp/enable_sms
/etc/init.d/httpd restart
 
Hierbei wird lediglich der Webadmin neugestartet, es wirkt sich also auf den normalen Betrieb nicht aus. Danach einfach den Webadmin neu laden und im Bereich MANAGEMENT findet man SMS GATEWAY um dort das GATEWAY zu konfgurieren, während man im HOTSPOT Bereich dann auf SMS AUTHENTIFIZIERUNG umstellen kann.

 

Ich hab die Funktion gleich mal getestet und mir einen Gratis Account auf SMSTrade erstellt, dieser behinaltet grob 20 Gratis SMS, je nach Destination.

(mehr …)

SNMPv3 Konfig Beispiele

Für SNMPv3 brauchst man drei Elemente “Gruppe”, “User” und eine “View”. Die View ist quasi nochmals ein Filter, welche MIBs verfügbar gemacht werden. Oft reicht es dort  “iso” rein zu machen, was soviel heisst wie “alle MIB”, man kann ja via ACL einschränken, wer überhaupt verbinden darf. Nachfolgend ein paar Beispiele

Beispiel mit Verweis auf eine ACL

snmp-server group SNMPV3_GROUP v3 auth access SNMP_ACL
snmp-server user NEDI_SNMPV3_USER SNMPV3_GROUP v3 auth SHA SNMPv3_SHA_KEY priv aes 256 SNMPV3_AES_KEY  
snmp-server user CACTI_SNMPV3_USER SNMPV3_GROUP v3 auth SHA SNMPv3_SHA_KEY priv aes 256 SNMPV3_AES_KEY 
snmp-server user PRIME_SNMPV3_USER SNMPV3_GROUP v3 auth SHA SNMPv3_SHA_KEY priv aes 256 SNMPV3_AES_KEY
snmp-server user ISE_SNMPV3_USER SNMPV3_GROUP v3 auth SHA SNMPv3_SHA_KEY priv aes 256 SNMPV3_AES_KEY  
snmp-server view SNMPV3_VIEW iso included 

Die ACL ziehst du auf der Gruppe oder dem User an. Ums nicht unnötig zu verkomplizieren, würd ichs jeweils auf der Gruppe anziehen und nicht auf dem User. Theoretisch kann man sogar auf User und Group Level machen.

Beispiel ohne ACL mit nur einem User

snmp-server group NEDI_SNMPV3_GROUP v3 auth 
snmp-server user NEDI_SNMPV3_USER NEDI_SNMPV3_GROUP v3 auth SHA SNMPv3_SHA_KEY priv aes 256 SNMPV3_AES_KEY  
snmp-server view SNMPV3_VIEW iso included 

Sollte das Management kein SHA/AES256 unterstützen, kannst du die Verschlüsselung auch runterschrauben:

 

snmp-server group NEDI_SNMPV3_GROUP v3 auth 

snmp-server user NEDI_SNMPV3_USER NEDI_SNMPV3_GROUP v3 auth SHA SNMPv3_SHA_KEY priv aes 128 SNMPV3_AES_KEY 

snmp-server view SNMPV3_VIEW iso included 

Der Key wäre in den Beispielen jeweils: SNMPv3_SHA_KEY

Under zur Verschlüsselung wird verwendet: SNMPV3_AES_KEY 

Beispiel anhand WCS:

2.1 Configure and troubleshoot DNS, DHCP, NTP, syslog, and SNMP

NTP 
 
 
NTP Server ohne selber NTP Client geht nicht auf allen Switchen, da nicht alle eine Batterie für neustarts haben.
 
Etwas detailierter ist NTP auch in diesem Posts erklärt.
 
Syslog
 
 
 
 
DHCP:
 
Wird an der Prüfung nur auf IOS Basis gefragt, keine Pools auf Windows!
 
 
 
 
 

(mehr …)

1.4.b End-to-end QoS

Ideology von QoS
 
Traffic wird am Eingangspunkt markiert, dieser bildet gleichzeitig die Aussengrenze des sogenannten “Trusted bounderie“
innerhalb dieser Zone wird der Markierung vertraut. Wenn ein Gerät bereits ein Marking liefert, und man diesem vertraut, erweitert man den „Trusted bounderie“
 
 
Accessport:     DSCP
Layer3 Port:     DSCP
Trunk:              DSCP / COS
WLC:               COS
HREAP/AAP:   COS  
 
 
 
Die wichtigsten Klassifikationen
 
 
 
 
 
 
 
 
 
 
 
Übersetzungstabelle zwischen DSCP und PHB
 
 
 
Umrechnen:
 
 
Problem mit Default mapping tables!
 
Beim wechsel von DSCP zu COS und rückwärts verändert sich der Wert:
 
 
 
 
 
 
 
 
 
 
 
QoS Konfigurieren
 
1) QoS aktivieren
2) Definiere QoS Maps
3) set Trust Boundaries
4) Markiere selber / Überschreibe die Markings
 
 
 
 
Mapping sollte angepasst werden damit DSCP 46 auf COS 5 matched und COS5 zurück auf DSCP46
 
 
 
 
 
 
Zum selber markieren verwendet man policy maps:
 
– ACL definieren
– Class-map definieren
– policy-map definieren
– via service-policy auf interface anziehen.
 
 
 
ACL:
 
 
 
Es wird in von dem remote office ins lokale Netz gematched, weil in die andere Richtung (WAN) die markings gedropped wurden. (Zumindest muss man davon ausgehen)
 
 
Class-map:
 
 
 
Policy-map:
 
 
service-policy auf interface anziehen.
 
 
overview:
 
 
 
 
 
LAB Tipp: Always check pre configs!
 
 
 
 
 
 
 
 
 
 
 

1.6.d Basic EIGRP

 
Autonomous System Number muss matchen!
 
 
 
 

Passive Interface

 
gleiches Konzept wie OSPF per default abschalten und per Interface anschalten:
 
 

Default Route

 
Static route lokal anlegen und dann redistributen:
 
 
 

Router ID

 
„Highest IP Adress of loopback or physical Interface“
 
 
Wichtig das Keyword „always“ wie bei OSPF damit die Route nicht im OSPF verschwindet, sollte die statische 0 Route ungültig sein.
 
 
 
Vorsicht mit MSDP im Multicast teil, es kann sein dass dort Loopback0 auf beiden Switche die gleiche IP erhält, man sollte in so Fällen sicherstellen, dass die Router ID unique bleibt / ist.
 
 

Tshoot

 
 
 
 
 
 
 

1.6.c Basic OSPF

OSPF ist wahrscheinlich das es dran kommt, auch hier wird jedoch ein CCNA/CCNP Level gefragt, fancy redistributing oder cost / load Manipulationen sind nicht zu erwarten.
Wichtig ist, dass man während der Prüfung an die Router ID denkt, möglich dass OSPF am Anfang konfiguriert wird und man später beim Multicast Teil mit MSDP rumfummelt und keine eindeutigen Router ID’s mehr hat.
 
Die Devise hier heisst: Read carefully und Keep it as simple as possible!
 
 
 
 
 
 
 
 
Da man via Console verbunden ist, kann man relativ einfach Live- verifien:
 
 Auf den Trunks erscheint jedes VLAN als Nighbor:
 
Möglicherweise ist verlangt, dass man nur in einem bestimmten VLAN eine nighborship formt, das macht man mit Passive Interfaces
 
 
 

Passive Interface

 
 
Per interface ist ziemlich umständlich, daher macht es mehr Sinn generell abzuschalten und explizit anzuschalten:
 
 
 
 
 

Default Route

 
 
Funktioniert nur wenn eine Default route von einer anderen Quelle (zb. static route) gelernt wurde, wenn diese jedoch gelöscht wird, wird sie auch im OSPF wieder gelöscht, daher unbedingt “always” dahinter setzen:
 
 
 
 

Router ID

 
„Highest IP Adress of loopback or physical Interface“
 
Sorg unter anderem dafür, dass keine Routing Loops entstehen.