Die Konfiguration eines Patton 4118 wurde im letzten Artikel beschrieben. Damit nichts verloren geht, sollte man regelmäßig die Konfiguration sichern. Das ganze zu Fuß zu machen macht keinen Sinn also automatisch. Aber wie?

Meine erste Idee

Meine erste Idee war die Sicherung über Telnet. So hat man auch früher die Konfiguation von Cisco Switches gesichert. Ein Script verbindet sich per Telnet auf das Gerät, listet die Konfiguration und sichert sie in einer Datei. Das würde mit den Pattons auch funktionieren. Allerdings gibt es eine bessere Möglichkeit.

Besser ist …

Es gibt die Möglichkeit die Konfiguration per TFTP zu sichern. Nicht als Cronjob auf dem Gerät selbst, sondern mit einem SNMP Aufruf (siehe SNMP Community zum schreiben im letzten Artikel). Dazu gibt es mehrere OIDs mit denen man

1. den TFTP Server
2. den TFTP Pfad / Dateinamen

setzen kann. Des Weiteren gibt es eine OID die die Sicherung ausführt und eine um den Erfolg zu prüfen.

In ein Script gepackt …

… sieht das ganze dann so aus:

#!/bin/bash
#
# Do Patton devices upload their current config via tftp
#  -> for Backup
#
# .1.3.6.1.4.1.1768.100.3.1.1.0 = INTEGER: noOp(0)
#  -- configsave $CLIENT SMARTNODE-MIB::uploadExecute.0
# .1.3.6.1.4.1.1768.100.3.1.2.0 = STRING: "10.21.3.10"
#  -- SMARTNODE-MIB::uploadTftpServerAddress.0
# .1.3.6.1.4.1.1768.100.3.1.4.0 = STRING: "moe-pat05_20110929.cfg"
#  -- SMARTNODE-MIB::uploadTftpServerPath.0
# .1.3.6.1.4.1.1768.100.3.1.5.0 = INTEGER: success(1)
#  -- SMARTNODE-MIB::uploadStatus.0
UPLOAD_SERVER="10.21.3.10"
UPLOAD_FILENAME="_`date +%Y%m%d`.cfg"
UPLOAD_CLIENTS="patton01 patton02 patton03 patton04"

for CLIENT in $UPLOAD_CLIENTS
 do
 snmpset -v 1 -c configsave $CLIENT .1.3.6.1.4.1.1768.100.3.1.2.0 s $UPLOAD_SERVER >/dev/null
 snmpset -v 1 -c configsave $CLIENT .1.3.6.1.4.1.1768.100.3.1.4.0 s "${CLIENT}${UPLOAD_FILENAME}" >/dev/null
 snmpset -v 1 -c configsave $CLIENT .1.3.6.1.4.1.1768.100.3.1.1.0 i 1 >/dev/null
 sleep 3
 STATUS=`snmpget -v 1 -c nagios $CLIENT .1.3.6.1.4.1.1768.100.3.1.5.0`
 if [[ $STATUS =~ failed ]]
 then
 echo "$CLIENT: tftp Backup via snmp failed"
 fi
done

Damit liegen die Konfigurationen mit Namen patton01_20111217.cfg im TFTP Verzeichnis des – in meinem Fall – VoIP Servers. Das ganze hübsch in einen Cronjob verpackt und fertig ist die Sicherung.

Der nächste Hardware “Baustein” ist ein Analog Gateway. Wie in Season 3 bereits beschrieben werden die Geräte von Patton eingesetzt.

Konfiguration

Die Patton Geräte sind von der Konfiguration her den Geräten von Cisco sehr ähnlich. Es gibt eine serielle Konsole, Zugriff per Telnet oder auch per Webfrontend.

IP Adresse

Zuerst einmal wäre eine IP Adresse hübsch. Also verbinden wir uns mit dem seriellen Kabel mit dem Gateway und nehmen das Terminalprogramm unseres Vertrauens (GtkTerm, minicom, …). Die Anmeldung geschieht mit Benutzernamen “admin” und Passwort “.”. Damit ist man angemeldet. Nun in den erweiterten Modus -> enable & configure.

IP Adresse und Default Gateway vergeben mit:

context ip router

  interface LAN
    ipaddress 10.21.3.122 255.255.255.0

context ip router
  route 0.0.0.0 0.0.0.0 10.21.3.201 0

port ethernet 0 0
  medium auto
  encapsulation ip
  bind interface LAN router
  no shutdown

Damit sollte das Gateway über die LAN Schnittstelle 0/0 über die IP 10.21.3.122 erreichbar sein.

Telnet oder Web?

Da das Gerät nun über das Netzwerk erreichbar ist, hat man nun die Qual der Wahl. Hat man die wirklich?? Ja hat man. Es geht prinzipiell alles über CLI als auch über das Webfrontend. Die Grundkonfiguration (oder Template) kann man – sobald ein Beispiel vorhanden ist – in einem Editor anpassen und dann einfach per Copy&Paste im Terminalfenster an das Gateway weitergeben. Das geht um einiges einfacher als sich alles immer über das Webfrontend zusammen zu klicken.

Für andere Dinge (dazu kommen wir noch) ist das Webfrontend allerdings besser geeignet, bzw. einfacher.

Die Logik

Die Überschrift ist komisch – passt aber. Es ist eine eigene Logik die Patton innerhalb der Geräte anwendet. Es gibt verschiedene Contexte die auf verschiedene Interfaces gebunden werden (können) – das ganze läuft über Contexte und Bindings. Da die Konfiguration jedoch – so denke ich – bei fast allen recht gleich ist, sollte ein erklärtes Template den meisten eine gute Ausgangsbasis darstellen. Das gibt es gleich.

Die Logik zum Routen der Calls sieht so aus, dass man alles über 3 “Tabellen” abhandelt (kann man bestimmt auch anders machen). Dadurch ist man flexibel für viele Anforderungen und hat trotzdem einen relativ kompakten überblick über die aktuelle Konfiguration (Nebenstellen <-> Ports). Ein Anruf von “Außen” (über LAN an das Gateway) kommt zuerst einmal in das Routing Table “RT_SIP_IN”. Dort kann beispielsweise die Nummer bearbeitet werden (nur ein Beispiel), bevor es dann weitergeht in die “RT_LOCAL”. Innerhalb der RT_LOCAL wird dann entschieden an welchen Port der Anruf weitergeleitet wird. Dazu wird einfach die Nummer der Nebenstelle direkt auf ein Interface gebunden. Damit ist der Anruf zugestellt.

Ein Anruf von einem analogen Port aus funktioniert vergleichbar. Der Anruf landet zuerst in der Routing Table “RT_FXS_IN”. Dort kann je nach dem die ein oder andere Funktion ausgeführt werden, bevor es dann weitergeht in die RT_LOCAL. Dort wird entschieden wohin der Anruf geht. Würde der Anruf in unserem Beispiel an die 10 gehen, so würde der Anruf innerhalb der RT_LOCAL direkt an das betreffende Interface weitergereicht. Der Anruf würde also innerhalb des Patton Gateways abgehandelt. Trifft jedoch die angerufene Nummer nicht auf eine der lokalen Nebenstellen, so wird der Anruf an den default Eintrag weitergeleitet. Also an das SIP Interface, welches auf ein zentrales Gateway oder auf die Asterisk zeigen sollte. In unserem Beispiel (siehe Season 3) gehen alle Anrufe der analogen Gateways über das zentrale Patton Gateway (E1 Gateway zum PSTN). Dadurch bleiben Analoge Anrufe komplett in der Hand der Gateways (also reine Hardware) ohne dass eine Modulation von Asterisk benötigt wird. Das ist gerade für Faxe oder Modems ein wichtiger Vorteil.

Konfigbeispiel

Ich versuche das ganze durch Kommentare möglichst verständlich zu machen

#----------------------------------------------------------------#
#                                                                #
# SN4118/JS/EUI                                                  #
# R5.8 2011-07-01 H323 SIP FXS FXO                               #
# 2011-10-31T10:12:08                                            #
# SN/00A0BA052727                                                #
# Generated configuration file                                   #
#                                                                #
#----------------------------------------------------------------#

cli version 3.20
clock local default-offset +02:00
webserver port 80 language en
# die SNMP Community zum auslesen von Statusinfos
snmp community nagios ro
# die SNMP Community zu schreiben von Werten
# diese ist sehr interessant und wichtig zum sichern der Konfiguration!!
snmp community configsave rw
# nun folgend die Hosts die SNMP abfragen duerfen und welche Rechte sie haben
snmp host 10.10.210.36 security-name monitoring
snmp host 10.10.210.36 security-name configsave
snmp host 10.21.3.10 security-name configsave
# NTP, die richtige Zeit ist wichtig
sntp-client
sntp-client server primary 10.10.210.201 port 123 version 4
# Hostname nicht nur fuer SNMP
system hostname patton03
system location "Schrank 1"
system contact netzwerkmanagement@einefirma.de

system

  ic voice 0
    low-bitrate-codec g729

profile ppp default

profile tone-set default

profile voip default
  codec 1 g711alaw64k rx-length 20 tx-length 20
  codec 2 g711ulaw64k rx-length 20 tx-length 20
  rtp traffic-class local-default
  # folgend nun diverse Einstellungen fuer die Faxuebertragung
  # die sich bewaehrt haben
  fax transmission 1 relay t38-udp
  fax redundancy low-speed 2 high-speed 3
  fax dejitter-max-delay 60
  fax max-bit-rate 9600
  fax detection fax-frames
  # gleiches fuer Modems
  modem transmission 1 bypass g711alaw64k rx-length 10 tx-length 10
  modem dejitter-max-delay 60
  no modem detection on-remote-fax-request

profile pstn default

profile ringing-cadence default
  play 1 1000
  pause 2 4000

profile sip default
  no autonomous-transitioning

profile aaa default
  method 1 local
  method 2 none

context ip router

  interface LAN
    # IP Adresse des LAN Interfaces
    ipaddress 10.21.3.122 255.255.255.0

context ip router
  # Routen werden hier gesetzt, folgend die Default Route
  route 0.0.0.0 0.0.0.0 10.21.3.201 0

context cs switch
  digit-collection timeout 3

  # im folgenden werden die Routing Tables definiert
  # RT_SIP_IN
    routing-table called-e164 RT_SIP_IN
    route default dest-table RT_LOCAL

  # RT_LOCAL (die zentrale Tabelle)
  # inklusive einiger Portzuordnungen
  routing-table called-e164 RT_LOCAL
    route default dest-interface IF_SIP_patton01
    route 334 dest-interface IF_FXS0
    route 275 dest-interface IF_FXS1
    route 285 dest-interface IF_FXS2
    route 311 dest-interface IF_FXS4
    route 312 dest-interface IF_FXS5
    route 322 dest-interface IF_FXS7
    route 270 dest-interface IF_FXS3
    # der folgende Service ist eine "Hunt-Group"
    # dabei wird auf mehrere verteilt (round-robin like)
    route 310 dest-service DFUE_310

  # RT_FXS_IN (Verbindung von analog Ports ausgehend)
  routing-table called-e164 RT_FXS_IN
    route default dest-table RT_LOCAL
    route .T dest-table RT_LOCAL

  # das Interface zur zentralen Patton
  interface sip IF_SIP_patton01
    bind context sip-gateway GW_SIP
    # die Routing Table auf das Interface binden
    route call dest-table RT_SIP_IN
    # die IP des Gateways
    remote 10.21.3.120

  # nun kommen die einzelnen Interfaces
  interface fxs IF_FXS0
    # binden an die RT_FXS_IN
    route call dest-table RT_FXS_IN
    caller-id-presentation pre-ring
    # die Nummer (fuer CLI)
    subscriber-number 334

  # und so weiter, fuer jedes Interface
  interface fxs IF_FXS1
    route call dest-table RT_FXS_IN
    subscriber-number 275

  interface fxs IF_FXS2
    route call dest-table RT_FXS_IN
    subscriber-number 285

  interface fxs IF_FXS3
    route call dest-table RT_FXS_IN
    subscriber-number 270

  interface fxs IF_FXS4
    route call dest-table RT_FXS_IN
    subscriber-number 311

  interface fxs IF_FXS5
    route call dest-table RT_FXS_IN
    subscriber-number 312

  interface fxs IF_FXS6
    route call dest-table RT_FXS_IN
    subscriber-number 313

  interface fxs IF_FXS7
    route call dest-table RT_FXS_IN
    subscriber-number 322

  # Das ist die Hunt-Group
  # es wird nach quasi rr verteilt auf
  # zwei Ports (siehe weiter unten)
  service hunt-group DFUE_310
    cyclic
    drop-cause normal-unspecified
    drop-cause no-circuit-channel-available
    drop-cause network-out-of-order
    drop-cause temporary-failure
    drop-cause switching-equipment-congestion
    drop-cause access-info-discarded
    drop-cause circuit-channel-not-available
    drop-cause resources-unavailable
    drop-cause user-busy
    # diese beiden Ports spielen mit
    route call 1 dest-interface IF_FXS4
    route call 2 dest-interface IF_FXS5

context cs switch
  no shutdown

context sip-gateway GW_SIP
   # hier wird das lokale interface erstellt, welches
   # SIP Pakete entgegen nimmt
   interface GW_IF
    bind interface LAN context router port 5060

context sip-gateway GW_SIP
  no shutdown

port ethernet 0 0
  medium auto
  encapsulation ip
  bind interface LAN router
  no shutdown

# nun wird jeder Port konfiguriert
port fxs 0 0
  encapsulation cc-fxs
  # gebunden wird dieses Interface an den Context IF_FXS0 (s. oben)
  bind interface IF_FXS0 switch
  # aktivieren
  no shutdown

# und so weiter fuer jeden Port
port fxs 0 1
  encapsulation cc-fxs
  bind interface IF_FXS1 switch
  no shutdown

port fxs 0 2
  encapsulation cc-fxs
  bind interface IF_FXS2 switch
  no shutdown

port fxs 0 3
  encapsulation cc-fxs
  bind interface IF_FXS3 switch
  no shutdown

port fxs 0 4
  encapsulation cc-fxs
  bind interface IF_FXS4 switch
  no shutdown

port fxs 0 5
  encapsulation cc-fxs
  bind interface IF_FXS5 switch
  no shutdown

port fxs 0 6
  encapsulation cc-fxs
  bind interface IF_FXS6 switch
  no shutdown

port fxs 0 7
  encapsulation cc-fxs
  bind interface IF_FXS7 switch
  no shutdown

Dieses Konfiguarationsbeispiel sollte für viele Installationen ein guter Anfangspunkt sein. Wenn ihr sie anpasst und einspielt, dann könnt ihr über die Weboberfläche die Routing Tables ganz einfach administrieren (Nummern <-> Ports). Das sollte dann nach der Erstkonfiguration auch das sein, was man so im laufenden Betrieb machen muss.

Übrigens: Um einen Eintrag zu ändern (gleiche Nummer, anderes Interface) legt man einfach einen neuen Eintrag mit der gleichen Nummer an

Wichtig noch …

Die Konfiguationsänderungen müssen – Cisco like – auf der CLI per

copy running-config startup-config

gesichert werden, bzw. auf dem Webinterface über “save”. Ansonsten sind die Änderungen bei einem Neustart verloren.

Das war die simple Variante

Was ich Euch hier gezeigt habe ist eine ganz simple Variante der Konfiguration. Man kann mit den Patton Gateways noch sehr viel mehr an Funktionen und allerhand Schweinereien treiben. Ein paar Funktionen werde ich noch zeigen, wenn es an das zentrale Gateway geht.

In der Season 4 hatte ich bereits die Aastra Stationen erwähnt. Die Konfiguration dieses Gerätes möchte ich nun beschreiben.

Requirements

Naja, also zuerst einmal benötigt man die Basisstation Dabei ist auf das “L” zu achten. Es gibt auch eine Version ohne “L”. Diese ist nicht für standard SIP sondern für die proprietären Anlagen von Aastra gedacht und funktioniert nicht mit unserer Anlage.

Möchte man mehr als 2 Basisstationen nutzen, also einen Cluster aufbauen, so benötigt man eine CD von Aastra. Die CD hat den Namen “OMM Activation Kit” und beinhaltet die Software & Firmware; interessanter ist allerdings der Lizenzkey auf der CD. Die CD kostet irgendwas zwischen 10 und 20€. Ohne diese Lizenz kann man jedoch nur zwei Basisstationen betreiben. Das ganze ist im Internet nur sehr schwer zu finden und auch die Vertriebsmenschen von Aastra kennen sich leider damit nicht aus. Damit ihr nicht auch so lange suchen müsst füge ich hier einen Screenshot der CD an (-> Artikelnummer ). Die aktuelle Version der Software gibt es hier.

Weiterhin benötigt man einen TFTP Server in Reichweite der Basisstationen. Diese wird zum Bereitstellen der Firmware benötigt.

Booten?

Um die Basis zu konfigurieren muss das Ding ins Netz. Dann kann mit Hilfe des OM_Configurators (Java Applikation zu finden im Software Bundle, bzw. auf der CD) das Gerät gesucht werden.

Folgende Schritte sind dann notwendig:

1. use local config
2. IP Addresse vergeben
3. Netmask …
4. TFTP Server eingeben
5. TFTP file name (Firmware Datei aus dem Software Bundle, omm_ffsip.tftp)
6. OMM IP Address (in dem Fall seine eigene)
7. ggf Router

Wofür?

Man muss zuerst einmal verstehen wie diese Dinger arbeiten. Jedes für sich ist nämlich – auf deutsch gesagt – recht doof. Was man in dem OM_Configurator einstellen kann ist quasi schon alles. Mehr kann sich das Ding auch nicht merken. Bei jedem Start wird sich per TFTP ein Firmware Image gezogen – selbst diese ist nicht persistent auf dem Gerät.

Des Weiteren muss man wissen, dass es immer einen Master unter den Basisstationen gibt. Alle anderen Geräte bekommen gar keine Konfiguation. Sie suchen sich den Master und bekommen sämtliche Informationen und die Konfiguration von ihm. Auch die Information wo die Slave Stationen die Firmware finden wird intern ausgetauscht. Daher auch der Parameter OMM IP Address – OpenMobilityManager. Damit wird der Master festgelegt. Eine Basisstation die selbst die IP des Masters besitzt, erkennt damit automatisch dass sie die Führung hat.

Und weiter?

Hat man die erste Station so konfiguriert und startet sie neu, so wird das image per TFTP geladen und die Station ist per Webzugriff erreichbar. Benutzername “omm” und Passwort “omm” sollten den Zugang freigeben. Danach sind noch ein paar kleinere Systemeinstellungen zu machen. Ich möchte jedoch nur noch ein paar Dinge dazu schreiben.

• Unter dem Menüpunkt Basisstationen muss man einen Cluster erstellen, damit das Rooming funktioniert
• Unter dem Menüpunkt Endgeräte werden die Mobilen Endgeräte konfiguriert. Es gibt dabei zwei Möglichkeiten das ganze zu tun
• a) Die Basisstation wird in einen Zustand versetzt, in dem sie neue Geräte einfach aufnimmt und anzeigt
• b) Man legt die Mobilteile vorher an und registriert sie dann

Um Mobilteile zu registrieren nutzen wir die zweite Möglichkeit. Wir bestimmen die IPEI Nummer (quasi sowas wie die MAC eines DECT Telefons) und legen damit einen Account in der Basis an. Die Accountdaten müssen natürlich mit denen am Asterisk Server übereinstimmen (Nummer, Name, Passwort). Damit ist das Gerät hinterlegt und wird bei der Anmeldung automatisch der richtigen Nummer zugewiesen.

Bestimmen der IPEI:

“An einem Siemens Gigaset kann die IPEI Nummer (als HEX) mit folgendem Befehl angezeigt werden:
Menü öffnen, *#06# eingeben, die erste Zeile ist die IPEI als HEX.”

Um die IPEI von HEX auf Dezimal umzurechnen, kann man diese Website nutzen (oder eben diese Funktion dahinter möglicherweise lokal bereitstellen).

Wichtig zu wissen ist – gerade bei Siemens -, dass die PIN immer 0000 sein muss. Ansonsten funktioniert das anmelden des Mobilteils nicht.

Die Geräte laufen bischer absolut zuverlässig. Auf der Herstellerhomepage kann man auch einen userguide finden, der beispielsweise Auskunft darüber gibt was die Anzeige der LEDs auf der Gehäusevorderseite bedeutet.