Testování Cisco OnePK API

Testování Cisco OnePK API
Jan Černoch - CER0130
Abstrakt: Tato práce se zabývá testováním softwarového API OnePK od firmy Cisco,
určeného k programovému ovládání platformy Cisco IOS. Práce je rozdělená na dvě
části, první z nich popisuje co to softwarové API OnePK je a jaké jsou jeho možnosti.
Druhá se poté zabývá samotným testováním tohoto API na uvedené testovací topologii.
V druhé části jsou také uvedeny a vysvětleny zdrojové kódy vytvořené za účelem
testování.
Klíčová slova: OnePK, Cisco, API, Python, GNU/Linux
1 Úvod..............................................................................................................................2
2 Softwarové API Cisco OnePK.......................................................................................2
2.1 Vlastnosti...............................................................................................................2
2.2 Podpora..................................................................................................................2
2.3 Instalace.................................................................................................................2
2.4 Konfigurace na síťových zařízeních Cisco............................................................3
3 Testování OnePK...........................................................................................................3
3.1 Testovací topologie................................................................................................3
3.2 Testovací programy................................................................................................4
4 Závěr............................................................................................................................11
5 Reference.....................................................................................................................11
prosinec 2014
1/11
1 Úvod
Cisco's One Platform Kit (dále jen OnePK) je softwarové API pro programové ovládání platformy Cisco,
součást tzv. software-defined networking (SDN).
Toto API umožňuje ve vybraných programovacích jazycích vytvářet programy, které mohou ovládat sí ťové prvky od firmy Cisco, měnit jejich konfiguraci, reagovat na nejrůznější události, které v síti resp. na zařízení nastanou, atp. Takto napsaný program může běžet buďto na samostatném serveru připojeném do sítě
nebo přímo na některém ze síťových prvků (většinou některém ze směrovačů), které toto API podporují.
2 Softwarové API Cisco OnePK
2.1 Vlastnosti
Vzhledem k tomu, že OnePK je relativně nový projekt firmy Cisco, obsahuje zatím podporu pouze pro
určité základní oblasti:
• Získávání informací o zařízení (včetně všech jeho síťových rozhraní) a statistik síťového provozu na
těchto rozhraních.
• Reakce na nejrůznější události, které mohou na síťovém zařízení potažmo v celé počítačové síti nastat
(např. reakce na události CDP protokolu, změnu stavu nebo adresy síťového rozhraní, umožňuje reagovat na události spojené se statistikou provozu na síťovém rozhraní, případně reagovat na zápis do sys témového logu zařízení, atp.).
• Statické směrování (změna směrovací tabulky, reakce na změnu směrovací tabulky, apod.).
• ACL – a to jak L3 ACL, tak i L2 ACL.
• Tzv. VTY = otevření virtuální konzole a posílání textových příkazů přímo z programu.
• AAA = Autentizace, Autorizace a účtování (Accounting).
• Umožňuje zachytávat a reagovat na příkazy zadávané přímo na konzoli (nebo přes SSH) síťového za řízení.
• Obsahuje datové třídy a metody pro zjištění topologie sítě (zatím pouze pomocí protokolu CDP).
I když API podporuje pouze základní oblasti práce se síťovými zařízeními firmy Cisco, tím, že umožňuje
otevření virtuální konzole a zadávání přímo textových konfiguračních příkazů, se z něj stává komplexní ná stroj, ovšem za cenu, že programování takové aplikace nebude tak pohodlné jako v případě využívání tříd,
jejich metod a funkcí API.
Nutno podotknout, že hlavním cílem OnePK není konfigurace síťových zařízení, nýbrž právě reakce na
nejrůznější události (tzv. event-driven programming).
2.2 Podpora
Aktuální verze OnePK využívaná v této práci je verze 1.3.0.
Programovací jazyky
OnePK je k dispozici pro následující programovací jazyky:
• C/C++
• Java
• Python (pouze ve verzi 2.7, nikoli 3.0 a vyšší) – tato práce se dále bude zabývat pouze touto verzí.
Síťová zařízení firmy Cisco
OnePK je podporováno následujícími verzemi operačního systému IOS:
• Cisco IOS XE 3.12.0S
• Cisco IOS XR 5.2.0
• Cisco IOS Release 15.4(2)T a vyšší
2.3 Instalace
Tato práce se zabývá pouze verzí pro programovací jazyk Python a operační systém GNU/Linux. Instalaci
lze provést několika způsoby.
prosinec 2014
2/11
Pomocí instalačního skriptu
Po stažení a rozbalení samotného OnePK se v tomto adresáři nachází skript setup.py, který stačí spustit
následujícím způsobem a instalace poté proběhne automaticky.
$ python setup.py install
Nakopírování do systémových knihoven
Samotná knihovna OnePK se nachází po rozbalení archívu v adresáři onep.
Lze ji tudíž přímo používat jako lokální knihovnu, tzn. po nakopírování tohoto adresáře do adresáře s
vlastním programem ji lze v tomto programu naimportovat jako lokální knihovnu.
Adresář onep lze také jednoduše nakopírovat do systémových knihoven využívaných jazykem Python,
které se standardně nachází v adresáři /usr/lib/python2.7/site-packages.
All-in-One Virtual Machine
Společnost Cisco také poskytuje tzv. All-in-One Virtual Machine, což je virtuální obraz operačního systému (konkrétně distribuce GNU/Linuxu Ubuntu), ve kterém jsou předinstalovány verze pro všechny tři pod porované programovací jazyky včetně vývojových prostředí pro tyto jazyky. Stačí jej tedy pouze spustit v
některém z virtualizačních nástrojů (např. VirtualBox nebo VMWare) a začít používat.
Tento operační systém také obsahuje předpřipravenou virtuální topologii skládající se ze tří virtuálních
zařízení IOSv verze 15.4, což je operační systém IOS speciálně zkompilovaný pro platformu x86, takže je
možné jej spustit v nějakém z virtualizačních nástrojů (např. Qemu nebo KVM).
2.4 Konfigurace na síťových zařízeních Cisco
Konfigurace OnePK na síťových zařízeních Cisco se provádí v konfiguračním režimu následovně:
(config)#onep
(config-onep)#transport type tls disable-remotecert-validation
(config-onep)#service set vty
První řádek změní režim na konfigurační režim OnePK. Druhým řádkem se poté specifikuje způsob připojování OnePK aplikací k tomuto zařízení. Aktuální verze OnePK již umožňuje pouze šifrované přihlašování pomocí TLS. Volba disable-remotecert-validation určuje, že síťové zařízení bude autentizováno
vlastním tzv. self-signed certifikátem, tzn. že certifikát nebude ověřený žádnou certifikační autoritou. Po slední řádek poté povoluje otevření virtuální konzole přímo v OnePK programu a zadávání textových
konfiguračních příkazů z tohoto programu.
Na síťovém zařízení je také třeba mít nastaveného alespoň jednoho uživatele s heslem.
3 Testování OnePK
Testování knihovny OnePK probíhalo pomocí několika programů, které byly vytvořeny přímo za účelem
otestování jednotlivých funkčností tohoto API. Jeden z programů se zabývá získáním statistik ze síťového
zařízení, další se zabývá statickým směrováním. Třetí program je zaměřen na ACL a poslední na konfiguraci
OSPF.
Testování probíhalo na testovací topologii, která byla navržena speciálně pro tuto práci.
3.1 Testovací topologie
Testovací topologie použitá v této práci vypadá následovně:
prosinec 2014
3/11
Obrázek 1: Testovací topologie
V testovací síti je nastaveno statické směrování tak, že veškerý provoz mezi sítěmi 10.10.10.0/24 a
10.10.12.0/24 prochází přes směrovač R3.
Testování probíhalo na dvou sítích uvedené topologie.
První z nich byla vytvořena v nástroji GNS3 (verze 0.8.7). Jako operační systém pro směrovače R1-R4
byl použit dříve zmiňovaný IOSv (verze 15.4) z All-in-One Virtual Machine, který byl provozován ve virtualizačním nástroji QEMU.
Druhá síť byla vytvořena v laboratoři a jako směrovače R1-R4 byly použity směrovače Cisco 2901 (verze
IOS – 15.5).
V obou případech byl jako OnePK server použit 64 bitový operační systém GNU/Linux (distribuce Arch
Linux) s nainstalovaným programovacím jazykem Python verze 2.7.8 a knihovnou OnePK verze 1.3.0.
3.2 Testovací programy
Za účelem připojení a přihlášení se na síťové zařízení byla vytvořená následující třída Device využívaná
všemi dále uvedenými programy.
01 class Device():
02
def __init__(self, username, password, address):
03
self.application = NetworkApplication.get_instance()
04
self.device = self.application.get_network_element(address)
05
self.username = username
06
self.password = password
07
self.session_configuration = SessionConfig(SessionConfig.SessionTransportMode.TLS)
08
self.session_configuration.set_tls_pinning(None,
PinningHandler())
09
10
def connect(self):
11
self.device.connect(self.username, self.password,
self.session_configuration)
12
13
def disconnect(self):
14
self.device.disconnect()
15
16
def get_api(self):
17
return self.device
Tato třída obsahuje konstruktor a metody connect(), disconnect() a get_api().
Pro připojení se k nějakému zařízení je potřeba nejprve získat objekt představující toto zařízení. Na objekt
typu NetworkApplication je potřeba zavolat metodu get_network_element() přebírající jeden parametr a tím
je adresa cílového zařízení. Tento objekt potom také vrací metoda get_api(), aby na něj mohly být přímo volány metody, které obsahuje OnePK API. Připojení na takto získaný objekt představující síťové zařízení je
poté realizováno metodou connect() přebírající uživatelské jméno, heslo a konfiguraci připojení.
Konfigurace připojení je objekt typu SessionConfig a obsahuje především způsob připojení (aktuálně pouze pomocí TLS) – řádek 7. Ovšem právě díky nutnosti používat TLS je připojení poněkud složítější než poprosinec 2014
4/11
mocí klasických socketů, jak tomu bylo v dřívějších verzích OnePK. Nejjednodušší způsob je nastavit na síťovém zařízení autentizaci pomocí self-signed certifikátu a v OnePK aplikaci používat tzv. pinning (řádek 8),
jinak by bylo potřeba distribuovat na server, na kterém běží OnePK aplikace certifikáty každého zařízení, na
které se aplikace připojuje. Pinning se používá také například u SSH protokolu, kdy se každé zařízení identifikuje pomocí jednoznačného RSA otisku (tzv. fingerprint) a ten poté může být uložen do souboru
known_hosts a jednoznačně tak identifikovat, na jaké zařízení se SSH připojuje a zda se otisk nezměnil.
Aby bylo možno tuto možnost využívat i v OnePK aplikaci je potřeba vytvořit další třidu, jejíž objekt je
poté předán metodě set_tls_pinning() objektu SessionConfig.
01 class PinningHandler(tlspinning.TLSUnverifiedElementHandler):
02
def handle_verify(self, host, hashtype, finger_print, changed):
03
return tlspinning.DecisionType.ACCEPT_ONCE
Tato třída dědí ze třídy TLSUnverifiedElementHandler a obsahuje jedinou metodu handle_verify(). Pro
účely testování postačí tuto metodu implementovat tak, aby každé spojení bylo akceptováno, bez ohledu na
to, zda se otisk změnil, apod.
1. Program
První program má za účel otestovat možnosti získávání informací ze síťového zařízení. Informace, které
jsou pomocí něj získávány jsou následující: základní informace o zařízení a verzi operačního systému,
hostname a uptime zařízení, využití procesoru a paměti. Dále to jsou informace o síťových rozhraních, jako
název, status, MAC a IP adresa a základní statistiky provozu na každém z rozhraní. Program také zjišťuje
prvních 10 procesů, které nejvíce zatěžují procesor a zabírají nejvíce paměti na zařízení.
Výstup programu vypadá následovně:
********** Device Information **********
Product ID:
I
OSv
Processor:
IOSv Chassis
Serial Number:
9MUP86DBFE5KADL6GLDR4
Description:
Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Experimental Version 15.4(20140730:011659) [lucylee-pi25-2 107]
Copyright (c) 1986-2014 by Cisco Systems, Inc.
Compiled Tue 29-Jul-14 18:17 by lucylee
********** Running
Hostname:
Uptime:
CPU Utilization:
Memory:
Information **********
R1
03:05:34
0 %
260 MiB Free / 315 MiB Total
********** Interfaces Information **********
Name:
GigabitEthernet0/1
MAC Address: 00:AB:F4:87:F3:01
Link status: Administratively down
IP Address:
Statistics:
Reliability:
Load:
Rate:
Packets:
Dropped packets:
Error packets:
prosinec 2014
100.0 %
0.4 % in / 0.4 % out
0 Bps in / 0 Bps out
19 in / 0 out
0 in / 0 out
0 in / 0 out
5/11
Name:
MAC Address:
Link status:
IP Address:
GigabitEthernet0/0
00:AB:F4:87:F3:00
Operationally up
10.10.10.2/24
Statistics:
Reliability:
Load:
Rate:
Packets:
Dropped packets:
Error packets:
100.0 %
0.4 % in / 0.4 % out
0 Bps in / 0 Bps out
1856 in / 480 out
0 in / 0 out
0 in / 0 out
********** Processes Information **********
Top 10 processes (CPU):
0.00 %
1
Chunk Manager
0.00 %
2
Load Meter
0.00 %
3
PnP Proxy Daemon Listener
0.00 %
4
RO Notify Timers
0.00 %
5
Check heaps
0.00 %
6
Pool Manager
0.00 %
7
DiscardQ Background Mgr
0.00 %
8
Timers
0.00 %
9
WATCH_AFS
0.00 %
10
Crash writer
Top 10 processes (MEM):
1358 KiB
328 EEM Server
478 KiB
147 ONEP Network Element Process
291 KiB
312 EEM ED Syslog
271 KiB
37
RF SCTPthread
218 KiB
313 EEM ED Generic
194 KiB
1
Chunk Manager
153 KiB
269 Crypto IKEv2
148 KiB
95
mDNS
122 KiB
6
Pool Manager
94 KiB
289 IPSEC key engine
Získání těchto dat je poté pouze otázkou volání několika metod na objekt, který vrátí funkce get_api() objektu třídy Device.
01 device = Device(username, password, address)
02 device.connect()
03 device_api = self.device.get_api()
04
05
06
07
08
09
10
11
12
product_id = device_api.properties.product_id
processor = device_api.properties.processor
serial_number = device_api.properties.SerialNo
description = device_api.properties.sys_descr
hostname = device_api.properties.sys_name
uptime_sec = device_api.properties.sys_uptime
cpu_utilization = device_api.get_system_cpu_utilization()
memory_free = device_api.get_free_system_memory()
memory_total = device_api.get_total_system_memory()
prosinec 2014
6/11
Poněkud složitější už je to v případě jednotlivých síťových rozhraní. Nejdříve je potřeba získat jejich seznam:
13 interfaces = device_api.get_interface_list(InterfaceFilter())
Objekt InterfaceFilter umožňuje specifikovat filtr, která rozhraní mají být obsažena ve výsledném sezna mu (např. pouze Ethernet, apod.). V tomto případě budou vrácena všechna rozhraní, která jsou na zařízení
dostupná.
Informace o jednotlivých rozhraních se poté získávají podobně jako v případě informací o celém síťovém
zařízení:
14 name = interface.name
15 mac = interface.get_config().mac_address
16 status = interface.get_status().link
17 if status ==
InterfaceStatus.InterfaceState.ONEP_IF_STATE_ADMIN_DOWN:
18
status = "Administratively down"
19 elif status ==
InterfaceStatus.InterfaceState.ONEP_IF_STATE_OPER_DOWN:
20
status = "Operationally down"
21 elif status ==
InterfaceStatus.InterfaceState.ONEP_IF_STATE_OPER_UP:
22
status = "Operationally up"
23 address = interface.get_prefix_list()[0].address
24 netmask = interface.get_prefix_list()[0].prefix_length
25 ip_address = "{0}/{1}".format(address, mask)
Pro každé síťové rozhraní lze také získat objekt statistics, který obsahuje statistiku provozu na tomto rozhraní:
26
27
28
29
30
31
32
33
34
35
36
37
statistics = interface.get_statistics()
reliability = round(((statistics.reliability / 255.0) * 100), 1)
tx_load = round(((statistics.transmit_load / 255.0) * 100), 1)
rx_load = round(((statistics.receive_load / 255.0) * 100), 1)
tx_rate = statistics.transmit_rate_bps
rx_rate = statistics.receive_rate_bps
tx_packets = statistics.transmit_cum_packet
rx_packets = statistics.receive_cum_packet
dropped_in = statistics.in_packet_drop
dropped_out = statistics.out_packet_drop
error_in = statistics.in_error
error_out = statistics.out_error
Hodnoty na řádcích 28-30 jsou vráceny jako číslo v rozmezí 0-255, proto je potřeba je přepočítat na procenta.
Posledními daty, které program získává je seznam procesů, který je poté jednoduše seřazen nejdříve podle
využití procesoru, následně podle využité paměti.
38 processes = device_api.get_process_list()
39 processes.sort(key=lambda p: p.cpuUsage, reverse=True)
40 for p in processes[:10]:
41
print "{0:.2f} %\t\t{1}\t{2}".format(p.cpuUsage, p.processID,
p.processName)
42 processes.sort(key=lambda p: p.heldMemory, reverse=True)
43 for p in processes[:10]:
prosinec 2014
7/11
44
print "{0:.2f} %\t\t{1}\t{2}".format(p.cpuUsage, p.processID,
p.processName)
2. Program
Další z testovacích programů se věnuje problematice reakcí na události na zařízení resp. v samotné síti a
statickému směrování. Princip je, že program naslouchá na konkrétním síťovém rozhraní (v tomto případě na
síťovém rozhraní směrovače R1 připojeného k R3) a v případě změny stavu jednoho z těchto rozhraní, změní
směrování tak, aby veškterý provoz šel přes směrovač R2. Pokud je linka uvedena zpět do provozu, je statické směrování navráceno do původní podoby.
Základem jsou dvě třídy fungující jako listenery a čekající na událost. První z nich je třída MyInterfaceStateListener dědící ze třídy InterfaceStateListener, která reaguje na události změny stavu rozhraní lokálního zařízení (R1). Druhou ze tříd je poté třída MyInterfaceCDPListener, která dědí ze třídy CDPListener, která reaguje na události změny stavu rozhraní vzdáleného zařízení (R3) pomocí protokolu CDP.
Chování těchto dvou tříd je prakticky stejné, při zachycení události je zavolána metoda handle_event(),
která pouze ověří status rozhraní, resp. zprávu CDP protokolu, a podle toho zavolá metodu change_routing()
s potřebnými parametry (zda je linka funkční nebo ne), která změní směrování na směrovači R1.
01 class MyInterfaceStateListener(InterfaceStateListener):
02
def __init__(self):
03
super(MyInterfaceStateListener, self).__init__()
04
05
def handle_event(self, event, application):
06
if event.interface_state == InterfaceStatus.InterfaceState.ONEP_IF_STATE_ADMIN_DOWN or event.interface_state == InterfaceStatus.InterfaceState.ONEP_IF_STATE_OPER_DOWN:
07
application.change_routing("down")
08
elif event.interface_state == InterfaceStatus.InterfaceState.ONEP_IF_STATE_OPER_UP:
09
application.change_routing("up")
10 class MyInterfaceCDPListener(CDPListener):
11
def __init__(self):
12
super(MyInterfaceCDPListener, self).__init__()
13
14
def handle_event(self, event, application):
15
if event.notify_type ==
CDPEvent.CDPEventNotifyType.ONEP_CDP_ADD:
16
application.change_routing("up")
17
elif event.notify_type ==
CDPEvent.CDPEventNotifyType.ONEP_CDP_DELETE:
18
application.change_routing("down")
Objekty těchto tříd je poté potřeba nastavit jako listenery na určité síťové rozhraní:
19 state_listener = interface.add_state_listener(MyInterfaceStateListener(), InterfaceStatus.InterfaceStateEventType.ONEP_IF_STATE_EVENT_LINEPROTO)
20 cdp_filter = CDPFilter()
21 cdp_filter.notifyType = CDPEvent.CDPEventNotifyType.ONEP_CDP_ALL
22 cdp_listener = self.interface.add_cdp_listener(MyInterfaceCDPListener(), cdp_filter)
Samotná změna statického směrování poté probíhá v metodě change_routing():
23 def change_routing(status):
prosinec 2014
8/11
24
scope = L3UnicastScope("", L3UnicastScope.AFIType.IPV4, L3UnicastScope.SAFIType.UNICAST, "")
25
network = NetworkPrefix("10.10.12.0", 24)
26
if status == "up":
27
next_hop = [L3UnicastNextHop(device.get_interface_by_name("GigabitEthernet0/2"),
"10.10.11.6", scope)]
28
elif status == "down":
29
next_hop =
[L3UnicastNextHop(device.get_interface_by_name("GigabitEthernet0/1"),
"10.10.11.2", scope)]
30
route = L3UnicastRoute(network, next_hop)
31
route_operation = [L3UnicastRouteOperation(RouteOperation.RouteOperationType.REPLACE, route)]
32
33
34
routing = Routing.get_instance(device)
route_table = routing.app_route_table
route_table.update_routes(scope, route_operation)
Nejprve je potřeba definovat cílovou síť a tzv. next hop pro případ, kdy bude linka funkční a kdy ne (tzn.
síťové rozhraní a IP adresu směrovače, přes který půjde provoz). Poté je z cílové sítě a odpovídajícího next
hopu vytvořen objekt L3UnicastRoute, pomocí objektu L3UnicastRouteOperation je určeno, že daná cesta se
bude nahrazovat (nikoliv přidávat, či odebírat) a nakonec je tato operace aplikována na směrovací tabulku.
I přes to, že tento postup je uvedený (ovšem je označený jako neověřený) v oficiální dokumentaci OnePK
[5], z neznámého důvodu nepracuje správně – směrovací tabulka zůstane nezměněna.
Z tohoto důvodu je změna statického směrování implementována jiným způsobem, a to pomocí virtuální
konzole a textových příkazů.
24 main = "ip route 10.10.12.0 255.255.255.0 10.10.11.6"
25 backup = "ip route 10.10.12.0 255.255.255.0 10.10.11.2"
26
27
28
29
30
31
32
33
34
35
vty = VtyService(device)
vty.open()
vty.write("configure terminal")
if status == "up":
vty.write("no " + backup)
vty.write(main)
elif status == "down":
vty.write("no " + main)
vty.write(backup)
vty.close()
Nejprve jsou definovány příkazy pro obě statické cesty. Poté je otevřena virtuální konzole a podle stavu
linky je jedna cesta zakázána (pomocí prefixu no) a druhá povolena. Nakonec je virtuální konzole uzavřena.
Výsledek poté vypadá následovně:
$ traceroute 10.10.12.1
traceroute to 10.10.12.1 (10.10.12.1), 30 hops max, 60 byte packets
1 r1 (10.10.10.2) 0.751 ms 3.556 ms 3.658 ms
2 r3 (10.10.11.6) 57.948 ms 63.404 ms 63.419 ms
3 10.10.11.14 (10.10.11.14) 57.938 ms * *
Current route: Network: 10.10.12.0/24 Next hop: 10.10.11.2
$ traceroute 10.10.12.1
prosinec 2014
9/11
traceroute to 10.10.12.1 (10.10.12.1), 30 hops max, 60 byte packets
1 r1 (10.10.10.2) 6.825 ms 17.920 ms 18.055 ms
2 r2 (10.10.11.2) 47.745 ms 47.975 ms 48.035 ms
3 10.10.11.10 (10.10.11.10) 58.714 ms * *
Current route: Network: 10.10.12.0/24 Next hop: 10.10.11.6
$ traceroute 10.10.12.1
traceroute to 10.10.12.1 (10.10.12.1), 30 hops max, 60 byte packets
1 r1 (10.10.10.2) 0.751 ms 3.556 ms 3.658 ms
2 r3 (10.10.11.6) 57.948 ms 63.404 ms 63.419 ms
3 10.10.11.14 (10.10.11.14) 57.938 ms * *
3. Program
Třetí program je zaměřen na ACL. Testování spočívá v zakázání ICMP provozu na rozhraní směrovače
R1 připojeného k testovacímu serveru s OnePK.
01 acl = L3Acl(self.device.device, OnepConstants.OnepAddressFamilyType.ONEP_AF_INET, L3Acl.OnepLifetime.ONEP_PERSISTENT)
02
03
04
05
06
ace = L3Ace(100, False)
ace.protocol = OnepConstants.AclProtocol.ICMP
ace.set_src_prefix_any()
ace.set_dst_prefix_any()
acl.add_ace(ace)
07
08
09
10
11
ace = L3Ace(101, True)
ace.protocol = OnepConstants.AclProtocol.ALL
ace.set_src_prefix_any()
ace.set_dst_prefix_any()
acl.add_ace(ace)
12 interface = self.device.get_api().get_interface_by_name("GigabitEthernet0/0")
13 acl.apply_to_interface(interface,
Acl.Direction.ONEP_DIRECTION_BOTH)
Hlavním principem je vytvořit nejdříve ACL pro IPv4 a dále jej naplnit pravidly. Nejprve je vytvořen ob jekt L3Acl. Logická hodnota False znamená, že to bude pravidlo zakazující provoz (deny), nikoliv povolující
(permit). Poté je potřeba specifikovat protokol a zdrojovou a cílovou adresu (v tomto případě jsou obě adresy
nastaveny na jakoukoliv hodnotu (any). Nakonec je potřeba přidat toto pravidlo do ACL a aplikovat jej na
konkrétní síťové rozhraní v daném směru (v tomto případě v obou směrech).
$ ping 10.10.10.2
PING 10.10.10.2 (10.10.10.2) 56(84) bytes of data.
From 10.10.10.2 icmp_seq=1 Packet filtered
From 10.10.10.2 icmp_seq=2 Packet filtered
From 10.10.10.2 icmp_seq=3 Packet filtered
--- 10.10.10.2 ping statistics --3 packets transmitted, 0 received, +3 errors, 100% packet loss, time
1999ms
Bohužel, OnePK neobsahuje žádné metody, jak získat seznam pravidel na zařízení nebo na konkrétním síťovém rozhraní. Proto je potřeba to řešit podobně jako v předchozím případě pomocí virtuální konzole. Po mocí virtuální konzole je nejdříve získána konfigurace síťového zařízení a poté je pomocí regulárního výrazu
získán seznam ACL, které se na tomto zařízení nachází. Poté jsou tyto ACL odstraněny.
prosinec 2014
10/11
4. Program
Poslední z programů se zaměřuje čistě na konfiguraci síťového zařízení a to pomocí virtuální konzole.
Výsledkem tohoto programu je zprovoznění směrovacího protokolu OSPF. Tento program nevyužívá žádné
jiné prvky OnePK API, než je virtuální konzole. Vše je tedy automatizováno pomocí textových příkazů.
Program nejprve zjistí, zda na síťovém zařízení již běží nějaký OSPF proces. Jestli ne, tak jej spustí. Poté
program projde všechny dostupná síťová rozhraní, zjistí sítě, do kterých jsou připojena a umožňí zvolit, zda
tyto sítě zahrnout do směrování, či ne. Dále tento program umožňuje nastavit tzv. router-ID, umožňuje distribuovat do směrování statické cesty a také tyto cesty upravovat.
4 Závěr
Cílem této práce bylo otestovat softwarové API OnePK pro programové ovládání síťových zařízení
Cisco. Testování probíhalo na testovací síti pomocí čtyř programů, kdy každý z nich testoval určitou oblast
funkčnosti tohoto API. Testování proběhlo až na pár problémů relativně úspěšně.
Bohužel ne všechny vlastnosti, které jsou uváděny v oficiální dokumentaci tohoto projektu fungují zcela
správně (např. změna směrovací tabulky).
Dalším problémem bylo také to, že API obsahuje pouze základní možnosti jak programové pracovat se
zařízeními Cisco. Spousta, hlavně pokročilejších oblastí, ale i některé základní (např. seznam použitých
ACL) není v tomto API implementována. Pokud je potřeba některé z těchto pokročilejších oblastí využívat,
je nutno sáhnout po virtuální konzoli a textových příkazech, což ale rapidně zvyšuje náročnost programování
takovéto aplikace. Ovšem je také nutno podotknout, že hlavním cílem tohoto API není konfigurace síťových
zařízení, ale reakce na nejrůznější události, které mohou v síti nastat. A tento cíl se daří plnit bez sebe menších problémů.
Všechny výše zmíněné problémy jsou dány nejspíše tím, že tento projekt je projektem relativně mladým a
stále se vyvíjejícím, takže se dá s jistotou předpokládat, že seznam implementovaných možností se bude
rozšiřovat více a více.
5 Reference
[1] Cisco's One Platform Kit (onePK) [online]. Dostupné z:
http://www.cisco.com/c/en/us/products/ios- nx-os-software/one
pk.html
[2] Cisco's One Platform Kit. Cisco onePK Python Reference [online]. Dostupné z:
https://developer.cisco.com/site/onepk/documents/apireference/python/
[3] Cisco's One Platform Kit. OnePK Python Tutorials [online]. Dostupné z:
https://developer.cisco.com/media/onepk_python_tutorials/index.html
[4] Cisco's One Platform Kit. Release Notes: Cisco onePK SDK Version 1.3 [online]. Dostupné z:
https://developer.cisco.com/fileMedia/download/7513cf78-ef38-423282b5-21e36083d581
[5] Cisco's One Platform Kit. Cisco onePK Python Reference – Class Routing [online]. Dostupné z:
https://developer.cisco.com/media/onepk_python_api/onep.rou
ting.RoutingClass.Routing-class.html
prosinec 2014
11/11