«раздвоение» сетевого интерфейса

есть

ifconfig eth1:0 ...

ifconfig eth1:1 ...

...

это алиасы. Там один интерфейс как был так и остается. Это не то что нужно автору темы.

VLAN, если полученные интерфейсы в разных сетях

dummy, tun/tap

Да, алиас мне не подходит :( См. ниже причину.

Как использовать VLAN в моем случае - я не понял. Pi - подскажи плиз.

sdio - подскажи, пож-ста, а как можно применить dummy и tun/tap?

----------------------------- P.S. Зачем мне это все нужно...реально у меня пакеты с eth1 передаются по MII интерфейсу в микросхему, которая их рассовывает в 1 и 2 канал (не ethernet). Но со стороны linux - у меня только один интерфейс - eth1. Так вот мне нужен признак, по которому микросхема бы определила, в какой канал отдавать пакет. В простом случае могла бы подойти схема с алиасами (на основании source ip - определять канал), но т.к. у меня маршрутизатор, то source ip может быть любой. Поэтому нужно, чтобы эти два канала линукс видел как два интерфейса, а eth1 - был просто способ передачи пакетов. Может быть, сумбурно объяснил....

Не уверен это ли тебе надо, но все же:

# modprobe dummy numdummies=8
# ifconfig dummy0 1.2.3.4 netmask 255.255.255.0
# ifconfig dummy1 2.3.4.5 netmask 255.255.255.0
# ifconfig
dummy0    Link encap:Ethernet  HWaddr DA:CD:26:52:02:09
          inet addr:1.2.3.4  Bcast:1.2.3.255  Mask:255.255.255.0
          inet6 addr: fe80::d8cd:26ff:fe52:209/64 Scope:Link
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:210 (210.0 b)

dummy1    Link encap:Ethernet  HWaddr 8A:CB:62:18:A2:5D
          inet addr:2.3.4.5  Bcast:2.3.4.255  Mask:255.255.255.0
          inet6 addr: fe80::88cb:62ff:fe18:a25d/64 Scope:Link
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:70 (70.0 b)

дык мож карту в promiscuous mode перевести ?

а про vlan я упомянул, т.к. там все вреймы имеют таги, по которым эти феймы можно "рассовать" по каналам.

1. Насколько я понял, пакеты, отправленные на dummy, идут в никуда. Или нет? А если нет, то их надо как-то передать в eth1. brctl нельзя, т.к. интерфей, включенный в bridge, должен иметь IP 0.0.0.0 Может быть bonding?

2. promiscuous mode, возможно, и надо будет использовать. Но это - смотря от реализации.

3. VALN тэг - интересная мысль, но опять таки, VLAN назначается на какой-то интерфейс, а мне их надо два, а если назначить на eth1, то какой в этом смысл?

В принципе, есть еще вариант. Написать простенький сетевой драйвер myeth, который пакеты отправлять никуда не будет. Создать два интерфейса myeth0 и myeth1. Написать программку net_bridge. В ней создать три сокета sock(PF_PACKET, sock_raw, htons(ETH_P_ALL)) и привязать их bind-ом к 3-м интерфейсам. Потом в бесконечном цикле читать (recvfrom) из sock_myeth0 и sock_myeth1, и если тип пакета s_11.s11_pkttype == PACKET_OUTGOING - отправлять его (sendto) в сокет sock_eth1.

В сторону eth1 вроде бы все работает, проверял.

А вот обратно - такой вопросик. Приходит пакет извне, попадает в eth1. Драйвер eth1 обрабатывает этот пакета и передает linux-у (вроде, так и происходит, но я не уверен). Должне ли я также считывать в бесконечном цикле из sock_myeth1 и полученной передавать в myeth0/myeth1 или нет? Ведь если я буду делать sendto(sock_myeth0), то в драйвере myeth будет вызваться обработчик отправки пакета (hard_start_xmit), а мне нужно не передавать пакет в myeth0, а чтобы его обработало ядро, как пакет, полученный интерфейсом myeth0. P.S. наверное, это не очень красивый вариант, ведь эта прога хороша должна грузить проц, но пока других вариантов у меня нет :( Лучше бы, конечно, найти решение на уровне linux.

Возьми и доработай, если можешь (я нет) модуль dummy

> дык мож карту в promiscuous mode перевести ?

бридж автоматом переводит в promiscuous mode

создал dummy0, дал ему IP. запустил net_bridge, пакеты уходят, приходят в драйвер eth1.

Но, есть проблема с arp. Пингую через dummy0 комп, он мне отвечает, но у меня в arp его mac адрес не подставляется.

Если вручную прописать MAC компа, то и пинги будут ходить, и пакеты. Как вы думаете, что может быть? У eth1 ip 0.0.0.0. Получется, что драйвер eth1 получает arp-пакет с IP - передает его ядру, а ядро, т.к. у этого интерфейса нулевой ip - не добавляет запись в таблицу arp.

Как с этим бороть?

proxy_arp?

а как proxy_arp может помочь?

> позволяющий, наоборот, "раздвоить" интерфейс? т.е. создать из eth1 два интерфейса: myeth0 и и myeth1.

М.б. стоит уточнить на каком уровне раздвоить - на уровне роутинга или свитчинга?
Если свитчинг - линк есть линк.
Если нужно из eth карты с одним портом нужно сделать карту с N портами - то да, нужно только к конфигурации добавить упраляемый свитч 2/2+ уровня
.1q решает, но с другой стороны пакетам надо сделать untag.

Раздвоить нужно на уровне свитчинга. Т.е. линукс должен иметь два интерфейса myeth0 и myeth1, которые физически уходят в eth1, дальше с процессора по интерфейсу MII на микросхему, которая должна пакет отправить в 0 или 1-й канал. И, обратно, на прием, в сторону проца.

Я так понимаю, что это есть свитчинг?

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

Или имеется ввиду схема с VLAN?

Можно через tun/tap

Один из примеров когда-то лежал на http://projects.epca.com.ve/veth

Из описания:

The Universal TUN/TAP driver is a Linux module that creates a software ethernet card, with their own MAC address. This module is extensively used for tunnels and VPNs, because the kernel "sees" an ethernet device. But, the real network doesn't see this card... Until now.

VETH chooses a ethernet device specified by the user, puts it in promiscuous mode and "links" this device with a TAP device, relaying all the traffic from and to this real card.

When you send a packet thru the virtual ethernet created by VETH, this packet passes thru VETH, totally formatted (with the virtual MAC address), and VETH takes it and sends it, *RAW*, to the NIC card. Because is sent via raw, the ethernet kernel driver doesn't touch it, leaving the original MAC address and sending as is to thw REAL network. Conclusion: the net sees a new NIC card...

Because VETH puts the original NIC in promiscuous mode, VETH can see if there are traffic with destination the virtual card. VETH takes it, and sends to the TAP. Conclusion: the software has received a packet from the NIC "card"...

VETH isn't difficult to understand or to program. It was a 3-hour hacking.

Using VETH ==========

Using VETH is very easy. If you want to create a new interface (called veth0, for "virtual ethernet 0"), call it as is:

# vethd

VETH creates a new ethernet interface called veth0, linked to the existent eth0.

If you want to change that, check out the usage:

Usage: vethd [-v veth-device] [-e eth-device] [-m mac-address]

If some or all of them are not defined, these are the defaults:

veth-device veth0 eth-device eth0 mac-address Generated automagically (and dynamic) by kernel

As you can see, you can label the new ethernet at your own. For example, if you want to label your "new card" :) veth1:

# vethd -v veth1 VETH 1.0 - Virtual Ethernet Driver (C) MMIII by NИstor PeЯa <nestor@linux.org.ve> This software is GPL - See LICENSE for details

Attached veth1 into eth0

And now, you have a new interface called veth1:

# ifconfig veth1 veth1 Link encap:Ethernet HWaddr 00:FF:46:7B:29:C5 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:2586 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:526822 (514.4 KiB) TX bytes:0 (0.0 b)

As you can see, this act like a regular NIC device. Now, try to use a DHCP client:

Если надо могу куда заслать.

а где взять этот vethd?