[devel] net-scripts и иерархия интерфейсов

[devel] net-scripts и иерархия интерфейсов

[Denis Ovsienko]

Предисловие: это относится к той части машин с ALTLinux, которые
занимаются маршрутизацией, причём не просто eth0<->eth1, а немного
сложнее.

Господа, как у нас определяется порядок инициализации интерфейсов? Только
по алфавиту в /etc/init.d/network:calc_ifaces. ipsectun, iptun и sit по
алфавиту находятся после eth, но до plip и ppp, причём ppp вообще может
быть запущен как PPTP over ipsec over eth. Вдобавок ещё есть dvb,
pentanet и наверняка ещё куча имён. Для корректного поведения
системы хочу спросить мнения по следующим решениям:

1a. Модифицировать calc_ifaces, чтобы сначала поднимались физические
интерфейсы, не зависящие от канального уровня: Ethernet, DVB, WiFi, PLIP,
SBNI. Затем я подозреваю, что должны быть физические интерфейсы, которые
не поднимутся без канального уровня, например, ISDN-карты. Мне таких не
попадалось, но я думаю, найдутся. Кто может привести пример? Только затем
поднимать sit-, IP- и IPSec-туннели, а после них уже PPP. Почему? Потому
что туннели не уходят в даун при пропадании удалённой стороны и даже если они
по замыслу администратора должны были работать через PPP-интерфейс, то они
спокойно дождутся, пока этот интерфейс станет доступным. Наоборот же
работать не будет.

1b. Реализовать возможность записывать в /etc/sysconfig/network строчку
вида IFACEINITORDER='eth0 sit0 ppp0' и получать инициализацию именно в
этом виде, если всё же администратору виднее, как правильно.

2. Немного похачить ifup/ifdown-ppp и интегрировать их с уже существующим
pptp-client, он работает отлично, но совать его запуск в rc.local
несерьёзно. Да и ppp-watch не зря же придумали, а то приходится всякие
проверялки изобретать.

3. Полностью переписать net-scripts, интегрировав в них все фичи
netfilter: advanced routes, rules, tables, traffic control :-\ Как бы не в
следующей жизни.

P.S. У меня проскользнула мысль насчёт использования make (1), но пока не
могу предложить что-то осмысленное.

--
    DO4-UANIC

[devel] Re: net-scripts и иерархия интерфейсов

[Michael Shigorin]

On Thu, Oct 16, 2003 at 03:50:58PM +0300, Denis Ovsienko wrote:
> Затем я подозреваю, что должны быть физические интерфейсы,
> которые не поднимутся без канального уровня, например,
> ISDN-карты. Мне таких не попадалось, но я думаю, найдутся.

Конкретно ISDN, думаю, на тестирование тебе найдется.

> 2. Немного похачить ifup/ifdown-ppp и интегрировать их с уже
> существующим pptp-client, он работает отлично, но совать его

Эээ... здесь было озвучено как-то предложение (mike, mhz, ldv?,
inger?) по части SysV'изации процесса подъема/опускания
интерфейсов -- у меня оно родилось при рассмотрении содержимого
http://linux.kiev.ua/~mike/misc/ppp-scripts-20020904.tar.gz
(/etc/ppp/ip-{up,down}.local) перед очередным вываливанием на
публику.

Ведь опять же -- есть вещи, которые после передергивания
интерфейса может быть осмысленно сделать (сходить за почтой
[ppp], ...), причем в определенном порядке.

> запуск в rc.local несерьёзно. Да и ppp-watch не зря же
> придумали, а то приходится всякие проверялки изобретать.

Внимание, грабли: ppp-watch на ряде железа и линий (конкретно
LuckyLink на Сириус-115 при импульсных наводках от звонка) имел
обыкновение впадать в ступор, причем гугл по "ppp-watch problem"
или вроде того показал, что проблема известна, но не решена (по
состоянию на два года назад -- ALJ1.1).

> 3. Полностью переписать net-scripts, интегрировав в них все
> фичи netfilter: advanced routes, rules, tables, traffic control
> :-\ Как бы не в следующей жизни.

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

Хотя это не пивной вопрос.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] net-scripts и иерархия интерфейсов

[Peter V. Saveliev]

On Thu, 16 Oct 2003 15:50:58 +0300 (EEST)
Denis Ovsienko <pilot@altlinux.ru> wrote:

> 
> Предисловие: это относится к той части машин с ALTLinux, которые
> занимаются маршрутизацией, причём не просто eth0<->eth1, а немного
> сложнее.
<skip /> 

(мои 5 коп.)

За всё двумя руками "за". А ещё хочется добавить в net-scripts поддержку
vlan не только на уровне разрешения и установки типа имён, но и чтобы
vlan-интерфейсы можно было прописывать как ifcfg-vlan221 и т.п. Правда,
возможно, это уже есть, а я просмотрел, тогда FR отменяется как
неактуальный :)

Если не ошибаюсь, iptables нормально навешивает правила с опцией -i <if>,
даже если этого <if> ещё не поднято? Тогда, очевидно, можно будет сделать
такой порядок:

1) iptables
2) interfaces
3) iproute2

где iptables - это поднятие netfilter, как и сейчас; interfaces - скрипты
из /etc/sysconfig/network*, как предлагает Денис, затем отдельные
программы, работающие с интерфейсами, вроде vrrpd или vtund (залью
последний не сегодня/завтра); iproute2 - ip/tc инициализация, причём не
только cbq, но и написать бы (на досуге кропаю, как будет что-либо
достойное - выложу) скрипты сохранения/загрузки ip route, ip rule, а также
tc qdisc в полном масштабе, т.е. вместе с ingress и т.п., и tc filter.

На даный момент занят сборкой маршрутизатора, в котором как раз это всё
будет сделано с той или иной степенью кривости ;)

Кстати, может, кому будет интересно: освоили технологию, по которой есть
dhcpd/bootp сервер, к которому цепляются PXE-агенты, есть boot-сервер с
tftp/ftp/nfs, раздающий pxelinux, ядра, initrd - по tftp, корневые
файловые системы - по nfs, архивы корневых фс - по ftp.

При загрузке машина получает ядро, при необходимости - initrd. Дальше
либо клиент монтирует корневую фс по nfs, либо (скрипт в initrd) создаёт
фс в ramdisk, скачивает .tar.gz по ftp и разворачивает его туда, после
чего скачивает специфический etc.tar.gz и тоже разворачивает, делает
pivot_root, chroot, отмонтирует romfs, оставшуюся от initrd. Во втором
случае получаем не просто бездисковый сервер, но и сервер, не зависящий от
nfs, и, как следствие, нечувствительный к пропаданию сети.

Подобная схема оказалась удобна для работы маршрутизаторов,
radius-серверов, как работающих с БД, так и с details (в последнем случае
диск всё же есть, но используется только для /var/log/freeradius).

Что есть: vrrpd, в совокупности с monit он обеспечивает очень быстрое
переключение потока на резервный сервер.

Что будет: vtund, замечательная зверушка, бо туннелит буквально всё,
включая ethernet. По крайней мере, я не нашёл других нормальных реализаций
level2-туннеля.

Что хочется: сделал патч, по материалам vlan-howto, который позволяет
карточкам eepro100, 3c90x и tulip работать с vlan-пакетами от cisco,
которые могут быть больше максимального кадра на 4 байта. Соберу в
kernel-feat, выложу - если примут его, это будет неплохо.


-- 
Sincerely, Peter V. Saveliev

E-mail: peet@altlinux.ru
Jabber: peet@jabber.ru