[Sysadmins] обработка событий в connexion

[Sysadmins] обработка событий в connexion

[Peter V. Saveliev]

...

В следующей сборке connexion/ncsh, которая пойдёт в Сизиф через неделю, будет 
поддержка обработки событий на различных шинах, в частности, оно сможет 
реагировать на события netlink (подъём/опускание интерфейсов, маршрутов, 
правил rpdb, обработка пакетов -j ULOG и т.п.) и snmp traps (v1/2c/3) (т.е. 
можно будет перестраивать таблицы маршрутизации, файрвол или управлять 
процессами в ответ на мессаги от сетевых девайсов).

Отсюда вопрос. Если у кого-н.ть есть use cases, в которых эта функциональность 
может быть полезна -- самое время поделиться. Потому как хоть я и стараюсь 
делать максимально обощённый framework, но могу не учесть какой-либо 
неизвестной мне специфики.

-- 
Peter V. Saveliev

Re: [Sysadmins] обработка событ?

[Aleksey Avdeev]

Peter V. Saveliev пишет:
> ...
> 
> В следующей сборке connexion/ncsh, которая пойдёт в Сизиф через неделю, будет 
> поддержка обработки событий на различных шинах, в частности, оно сможет 
> реагировать на события netlink (подъём/опускание интерфейсов, маршрутов, 
> правил rpdb, обработка пакетов -j ULOG и т.п.) и snmp traps (v1/2c/3) (т.е. 
> можно будет перестраивать таблицы маршрутизации, файрвол или управлять 
> процессами в ответ на мессаги от сетевых девайсов).
> 
> Отсюда вопрос. Если у кого-н.ть есть use cases, в которых эта функциональность 
> может быть полезна -- самое время поделиться. Потому как хоть я и стараюсь 
> делать максимально обощённый framework, но могу не учесть какой-либо 
> неизвестной мне специфики.

  Классика жанра: подключение к двум провайдерам, один из которых
Corbina (т. е. pptp, через vpn сервер доступный _только_ через
маршрутизатор локалки)...

-- 

С уважением. Алексей.

Re: [Sysadmins] обработка событ?

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 3749 bytes --]

Peter V. Saveliev пишет:
> В сообщении от Tuesday 16 October 2007 12:59:31 вы написали:
>> Peter V. Saveliev пишет:
>>> ...
>>>
>>> В следующей сборке connexion/ncsh, которая пойдёт в Сизиф через неделю,
>>> будет поддержка обработки событий на различных шинах, в частности, оно
>>> сможет реагировать на события netlink (подъём/опускание интерфейсов,
>>> маршрутов, правил rpdb, обработка пакетов -j ULOG и т.п.) и snmp traps
>>> (v1/2c/3) (т.е. можно будет перестраивать таблицы маршрутизации, файрвол
>>> или управлять процессами в ответ на мессаги от сетевых девайсов).
>>>
>>> Отсюда вопрос. Если у кого-н.ть есть use cases, в которых эта
>>> функциональность может быть полезна -- самое время поделиться. Потому как
>>> хоть я и стараюсь делать максимально обощённый framework, но могу не
>>> учесть какой-либо неизвестной мне специфики.
>>   Классика жанра: подключение к двум провайдерам, один из которых
>> Corbina (т. е. pptp, через vpn сервер доступный _только_ через
>> маршрутизатор локалки)...
> 
> 
> А можешь расписать схему в ascii-art с пояснением, какая часть должна 
> реагировать на какое событие?
> 
> Спасибо.

Схема взаимосвязи интерфейсов:

HE -- хост система
|\
| lanbr -- бридж для квартирной локалки
| |\
| \ lan -- eth квартирной локалки
|  \
|   veth1040.0 -- veth для VE с DHCP
|\
| wp -- eth для ADSL модема (частная сеть: NAT/DNAT подняты на модеме),
|    резервный канал.
|\
| venet0 -- для VE не требующих veth (2 DNS`а, ntp и пр.)
 \
  wanbr -- бридж для работы с Сorbin`ой маршрут по умолчанию (основной
  |     канал)
  \
   veth1020.0 -- veth для VE с Crbin`овским шлюзом. Всё что ниже -- в
   |          данном VE
VE |
|\ |
| dmz -- veth со стороны VE
|\
| corblan -- eth, проброшенный в VE. Обеспечивает доступ к Corbin`овской

|         локалке (частная сеть) и VPN серверу в частности (Внимание: IP
|         VPN сервера белый, и данной сети _не_принадлежит_).
 \
  ppp0 -- PPTP тунель во внешний мир (основной канал). Маршрут по
       умолчанию.

Дополнения, косающиеся Corbina:

1. Штатный способ получения IP -- DHCP. Возможность взять фисированный,
внутриситевой, IP есть, но их диапазон в каждом сегменте ограничен
(зарезирвированы для серверов предоставляющих районнык ресурсы).

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

3. Часть локальных ресурсов (похоже, что все ресурсы принадлежащие самой
Corbin`е) имеют внешний IP, и доступны как через районный маршрутизатор,
так и через внешний канал (VPN). Но при доступе через VPN они считаются
внешними (скорость доступа и тарификация в соответствии с тарифом), а
при доступе через локалку (районный маршрутизатор) -- ограничений и
тарификации нет

4. VPN сервера (их сильно больше одного) имеют внешний IP и доступны
_только_ через районный маршрутизатор. Если при установке тунеля маршрут
доступа к VPN серверу будет переписан -- получим нерабочий тунель.

Что сделано сейчас (средствами etcnet):

1. Ресурсы, расположенные на хосте, доступны через обоих провайдеров.

2. К ресурсам доступным только через одного провайдера -- прописаны
статические маршруты.

3. default -- Corbina

Что хотелось бы иметь в конечном итоге:

1. Если доступны оба канала -- делим трафик между ними.

2. Если отвалился один их каналов -- default на оставшийся.

3. Если отвалился VPN тунель -- default на wp, но маршруты к локальным
ресурсам Corbina должны действовать...

4. Приоритизация трафика.

PS: Отправляю копию в sysadmins@.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 481 bytes --]