IP адрес на мост или на интерфейс

Maxim_Al

Не могу понять в чём практическая разница между выдачей IP адреса на мост или на физический интерфейс.
Т.е. есть 2 интерфейса, например igb0 и igb1. Они объединяются в мост BRIDGE0. Для доступа к устройству (интерфейсы с внешним белым адресным пространством) выделяется 1 адрес. Bот в принципе и вопрос IP должен быть на каком igb или на bridge0?
По логике, адрес нужен для устройства (т.е. для моста), а не интерфейса, и соответственно IP надо присваивать BRIDGE0. С другой стороны, согласно документации адрес должен быть на интерфейсе: "Only one interface on a bridge should have an IP address! Do not add multiple IP addresses in the same subnet on different bridge member interfaces. Other interfaces on the bridge should remain with an IP type of None."

rubic

@maxim_al
Разница в том, что интерфейс моста никогда не "падает" в отличие от физического интерфейса. Таким образом IP на мосту всегда доступен. Куда вешать - зависит от задачи, там в доке приведены примеры, когда оправдано применение нескольких IP на физ. интерфейсах моста.

Maxim_Al

@rubic said in IP адрес на мост или на интерфейс:

Таким образом IP на мосту всегда доступен.

ну это то понятно.

@rubic said in IP адрес на мост или на интерфейс:

там в доке приведены примеры,

Не видел таких примеров, но доки большие, ссылку можно?

pigbrother

@maxim_al said in IP адрес на мост или на интерфейс:

согласно документации адрес должен быть на интерфейсе: "Only one interface on a bridge should have an IP address!

Предположу, что единственый IP-адрес интерфейса, включаемого в бридж нужен для того, чтобы не потерять доступ к pfSense на время настройки бриджа.

@rubic , тут
http://mtu.net/~engstrom/configure-pfsense-bridge-over-multiple-nics-as-lan/
Предлагается после создания бриджа создать еще и Interface Group.
Насколько это необходимо?

rubic

@maxim_al

Note

Only one interface on a bridge should have an IP address! Do not add multiple IP addresses in the same subnet on different bridge member interfaces. Other interfaces on the bridge should remain with an IP type of None.

It is normally best to avoid such configurations as they can be problematic, but they can also be useful for several types of configurations, such as:

Bridging a wireless interface to a LAN
Transparent firewall (WAN/LAN bridge)
Filtering between portions of a single subnet

Edit: хотя возможно тут я путаю и последнее относится не к Note, а к предыдущему абзацу про net.link.bridge.pfil_member and net.link.bridge.pfil_bridge
В любом случае надо отталкиваться от задачи, чего сделать хотите, что не получается

rubic

@pigbrother
Я так понмаю, что для удобства фильтрации, так как "By default, traffic is filtered on the member interfaces and not on the bridge interface itself." Он их оюбъединяет в Interface Group и не надо писать правила в разных местах.

werter

Доброго.
Я бы еще и MAC address бриджу явно "придумал".
Есть вероятность, что MAC после перезагрузки пф может поменяться и у Win-клиентов в LAN всплывет на экране запрос по поводу выбора типа сети. Это легко проверить, кстати.

pigbrother

@werter said in IP адрес на мост или на интерфейс:

Есть вероятность, что MAC после перезагрузки пф может поменяться

Ну это будет, мягко говоря, недоработка со стороны разработчиков.