Подход к работе со свичами

[weldp]

Подход к работе со свичами

Привет Всем
Есть свичи(комутаторы) и надо разработать систему управления.
Так вот проблему представляют следующие случаи:

В общей сложности порт на свиче можно описать:
режим: tag / untag
vlan: 0 - x шт
Так вот в режиме untag - на порту может быть только: 0-1 vlan
Так вот в режиме tag - на порту должен быть один untag-vlan(native vlan), все остальные tag

1.Теперь нужно обработать ситуацию - порт untag->tag:
надо поменять режим работы и добавить если надо vlan

2. наоборот tag->untag:
надо удалить этот порт из всех вланов, только потом выставлять vlan

То есть в этой ситуации надо проверять

режим tag:
-есть native vlan
-порт добавляемый в vlan не присутствует как untag в нем же если требуется tag

режим untag:
-что данный порт не присутствует ни в одном из vlan'ов


Примеры что надо настраивать функции:
igmp
acl
rate-limit
IP-MAC-BINDING
vlan
ospf
routing
ip
dhcp
stp
и т.д.


Сама же настройка осуществятся способами:
по telnet/ssh
по snmp
закачкой config

В итоге это все значит что если писать 1-а функция=1 действие для конфигурации, то надо написать
=(количество функций*количество моделей+количество функций*количество ситуаций которые конфликтуют)*количество способов конфигурации

(количество ситуаций которые конфликтуют)-например нельзя добавить stp в несуществующий vlan, надо отключить ospf, настроить потом включить и т.д.

В общем хотел бы услышать совет - может можно частично шаблоны/сценарии как-то реализовать?

 

[dimagolov]

то надо написать

написать что? html страничек? так же как и любая друга веб-система:
1. отображаем состояние
2. собираем данные для изменения, валидируем их
3. производим изменения на железке и возвращаемся на п.1

очевидно, что то как отображать и что и как можно менять нужно хранить для разных девайсов в каком-то описании конфигураций.

за тебя спроектировать систему?

 

[weldp]

Автор оригинала: dimagolov
написать что? html страничек? так же как и любая друга веб-система:

за тебя спроектировать систему?

Хм...Я прошу совета как её спроектировать, а не "за меня" это сделать

Я сначала хотел подойти к делу так:

class SWITCH_MANAGE {  
/*
*  class, который управляет свичем через класс SWITCH_BASE
*/
public function vlan_add_port($vlan,$port,$mode){ }  
public function vlan_delete_port(){ }  
public function vlan_distroy(){ }  
public function vlan_add(){ }  
public function vlan_tag_port(){ }  
public function vlan_untag_port(){ }  
public vlan_port_changemode(){}
}

/*пример функции которая юзает class SWITCH_BASE*/
vlan_add_port($vlan,$port){
    $exist=SWITCH_BASE->vlan_is_exist($vlan);

    if($exist!=true){
          self::vlan_add($vlan)
      }
    $mode_now=SWITCH_BASE->vlan_port_mode_status();
    if($mode!=$mode_now){
         if(!self::vlan_port_changemode($mode))
               die("error change mode");
    }
        
      if(vlan_port_is_inport_exist()!=true){
       switch($mode){
            case "tag":              SWITCH_BASE->vlan_port_add_tag(); break;
            case "untag":       SWITCH_BASE->vlan_port_add_untag(); break;
     }

     }else{ log("already exist");}
   
}

class SWITCH_BASE {  
/*
* class с базовой функциональностью - каждая функция в нем делает одну вещь, но без всяких проверок
*/
public function vlan_is_exist(){ }  
public function vlan_create(){ }  
public function vlan_delete(){ }  
public function vlan_rename(){ }  

public function vlan_port_is_inport_exist(){ }  
public function vlan_port_mode_status(){ }  


public function vlan_port_add_tag(){ }  
public function vlan_port_delete_tag(){ }  
public function vlan_port_add_untag(){ }  
public function vlan_port_delete_untag(){ }  
public function vlan_port_changemode_untag(){ }  
public function vlan_port_changemode_tag(){ }  


}

Извиняюсь если наделал ошибок...

Так вот Я делаю class->SWITCH_BASE и class->SWITCH_MANAGE
Для каждого Вендора и модели переназначаю нужные функции из SWITCH_BASE, и из SWITCH_MANAGE

 

[dimagolov]

я не уверен, что нужно писать класс для каждой модели. даже наоборот, нужно писать универсальные методы, а особенности модели хранить в базе и подгружать их и использовать.

-~{}~ 27.11.09 10:40:

потому что у тебя выбор: или писать новый код для каждой новой модели или описывать ее в терминах конфигурации в базе. второе очевидно, что проще поддерживать. менять код придется разве что для поддержки (универсальной) каких-то принципиально новых фич, которые не были реализованы раньше.

 

[weldp]

Автор оригинала: dimagolov
я не уверен, что нужно писать класс для каждой модели. даже наоборот, нужно писать универсальные методы, а особенности модели хранить в базе и подгружать их и использовать.

потому что у тебя выбор: или писать новый код для каждой новой модели или описывать ее в терминах конфигурации в базе. второе очевидно, что проще поддерживать. менять код придется разве что для поддержки (универсальной) каких-то принципиально новых фич, которые не были реализованы раньше.

Можно пример как особенности отделить?...

 

[dimagolov]

e.g. таблица action -> command to execute, можно сделать именованные плейсхолдеры для параметров, чтобы подставлять их автоматом. такой себе шаблон для составления команд.

 

[weldp]

Автор оригинала: dimagolov
e.g. таблица action -> command to execute, можно сделать именованные плейсхолдеры для параметров, чтобы подставлять их автоматом. такой себе шаблон для составления команд.

Эти классы и должны были формировать... и должны были учитывать когда и какие команды и в какой последовательности идут...

Я тут подумал что если написать такого плана templat'ы правда Я со smarty не работал(скорее всего ошибки):

create vlan {$vlan-name}
config vlan {$vlan-name} tag {$vlan-tag}
config vlan {$vlan-name} ipaddress {$vlan-ip}

{foreach item=port key=vlan from=$vlan-delete-ports}
 config vlan {$vlan} delete port {$port}
{/foreach}

 
{foreach item=port from=$vlan-ports}
 config vlan {$vlan-name} add port {$port}
{/foreach}

Тогда наверное количество кода уменьшится

 

[dimagolov]

ну да, именно подобные шаблоны я и имел в виду