Добрый день!
Прошу помощи в решении вопроса. В контроллере WB7 необходимо задействовать 3 сетевых интерфейса
В настоящий момент при активации всех соединений теряется связь по eth1 и WB7 становится недоступным для подключения.
Добрый день.
Для начала какой релиз установлен на контроллере?
Ну и по вопросу:
Какие подсети используются на инттерфейсах, какие параметры, в частности маршруты контроллер получает по dhcp?
Какой вес маршрутов для соединений?
Какой должен быть?
Вот тут - пока непонятно. Перестает быть доступным - откуда? Из какой подсети, какой маршрут из этой подсети к контроллеру?
Контроллер Wiren Board 7.4.3, установленный release wb-2401 (as stable)
В параметрах интерфейса в настройках контроллера интерфейс eth0 IPv4 установлена галочка “Подключаться автоматически”, значение IPv4-DHCP , остальные настройки не менялись;
интерфейс eth1 IPv4 установлена галочка “Подключаться автоматически”, значение IPv4-DHCP, остальные настройки не менялись;
Интерфейс wb-gsm-sim1 установлена галочка “Подключаться автоматически”, значение IPv4-DHCP, остальные настройки не менялись.
Вот выгрузка команды ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether (здесь значение моего mac) brd ff:ff:ff:ff:ff:ff
inet 192.168.1.43/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
valid_lft 25181sec preferred_lft 25181sec
inet6 fe80::2ef3:58bc:a18a:d73d/64 scope link noprefixroute
valid_lft forever preferred_lft forever
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether (здесь значение моего mac) brd ff:ff:ff:ff:ff:ff
inet 192.168.121.2/24 brd 192.168.121.255 scope global dynamic noprefixroute eth1
valid_lft 48581sec preferred_lft 48581sec
inet6 fe80::a4eb:72fc:2fa7:286e/64 scope link noprefixroute
valid_lft forever preferred_lft forever
5: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 98:03:cf:34:e2:30 brd ff:ff:ff:ff:ff:ff
6: wlan1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 9a:03:cf:34:e2:30 brd ff:ff:ff:ff:ff:ff
7: dbg0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 1a:55:89:a2:69:43 brd ff:ff:ff:ff:ff:ff
8: usb0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 82:26:c7:ec:c6:99 brd ff:ff:ff:ff:ff:ff
12: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 3
link/ppp
inet 10.42.239.185 peer 10.64.64.64/32 scope global ppp0
valid_lft forever preferred_lft forever
inet 10.42.239.185/32 scope global noprefixroute ppp0
valid_lft forever preferred_lft forever
-Какой вес маршрутов для соединений? я не зная как определить, мне нужно чтобы с интерфейса eth0 был доступ в интернет и локальную сеть роутера, с wb-gsm-sim1 был доступ в интернет в случае если eth0 недоступен, с eth1 должен быть постоянный доступ в локальную сеть этого сегмента и из нее также должен быть доступ к контроллеру
-Перестает быть доступным - откуда? Когда я включаю интерфейс модема wb-gsm-sim1 или же eth0 у которых есть доступ к интернету и при этом включен свой DHCP то контроллер становится недоступным из интерфейса eth1 в который подключена сеть 192.168.121.2/24, ну как сказать недоступным, например из подсети 192.168.121… я могу его пинговать но там нет ПК с которого я могу зайти на web. А вот с другого сегмента этой сети с другим IP (назовем ее условно 10.112.121…) к этому IP контроллера WB я не могу подключиться и он становится недоступным для команды ping (хотя если назначить статический адрес без указания маски в eth0 и отключить при этом модем он становится доступным из eth1)
Какой маршрут из этой подсети к контроллеру? Маршрут из подсети интерфейса eth1 к контроллеру состоит из трех коммутаторов расположенных в трех разных подсетях условно напишу:
1 10.112.121.01 (Здесь я)
2. 10.110.121.01 (Промежуточный коммутатор)
3. 192.168.121.2 (это WB7)
Логику взаимодействия самих коммутаторов я не делал, но она работает безусловно, так как повторюсь что при условии выключенных соединениях eth0 и wb-gsm-sim1 ,или же при условии назначения на них статических IP (без указания маски подсети) доступ к контроллеру из через интерфейс eth1 есть.
Перефразирую, какие маршруты есть сейчас?
Посмотреть можно с помощью команды ip route например.
Без точного понимания желаемой маршрутизации, точнее соотношения весов маршрутов в локальные сегменты и дефолтных - я вряд ли смогу что-то осмысленное подсказать.
И по какому пути должен отправить контроллер пакет чтобы попасть в подсеть 10.112.121.0/24? Как (чем) этот маршрут в нем указан? Судя по наличию dhcp - опцией 249?
Ну, логично если дефолтный маршрут указывает в ближайший коммутатор.
Повторюсь, без схемы желаемых маршрутов (ну, если не говорить о bgp, например) можно реализовать передачей по dhcp маршрутов в локальные сегменты пожалуй.
Советую привлечь сетевого инженера.
Перефразирую, какие маршруты есть сейчас?
Прилагаю вывод команды
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.43 metric 55
default via 192.168.121.1 dev eth1 proto dhcp src 192.168.121.2 metric 305
default dev ppp0 proto static scope link metric 700
10.64.64.64 dev ppp0 proto kernel scope link src 10.241.22.65
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.43 metric 55
192.168.121.0/24 dev eth1 proto kernel scope link src 192.168.121.28 metric 305
Сами маршруты не настраивал, это все как я понимаю по умолчанию.
И по какому пути должен отправить контроллер пакет чтобы попасть в подсеть 10.112.121.0/24?
Контроллер должен работать в сети 192.168.121.0/24 включенной в eth1, ну и на сколько я понимаю он должен отправлять запросы на шлюз 192.168.121.1, а к его определенным IP портам уже настроен доступ из нужной подсети 10.112.121.0/24 (не знаю каким правилом). Контроллер работает и доступен из сети 10.112.121.0/24 только при условии что в него подключен только один интерфейс eth1.
К сожалению сетевого администратора я привлечь не могу, т.к. свою задачу он выполнил - контроллер с включенным одним сетевым интерфейсом доступен для взаимодействия по нужным портам, а дальше это не их проблемы, говорят настраивать свой контроллер, ну я и сам склоняюсь к тому что нужно что то изменить в настройках сетей контроллера.
В моем понимании нужно как-то сделать чтобы выход в инет у контроллера должен остаться только по интерфейсам eth0 (192.168.121.0/24) и wb-gsm-sim1, а по eth1 он должен работать в локальной сети. Я очень признателен за ваше участие в моем вопросе )
Нет, маршруты получены от dhcp.
И да - я вижу что тут метрика приоритетная у шлюза подсети 192.168.1.1
Если не желаете использовать анонс маршрутов через dhcp - то можно выставить приоритеты.
Ну как минимум сейчас - так и есть, дефолтный маршрут именно через этот шлюз.
Ну и ответы на все пакеты, в том числе полученные через eth1 - отправляться будут через дефолтный шлюз.
В принципе начать можно отсюда: https://dzen.ru/a/Y71fY96P5yobsJVB
Почитал рекомендуемую вами статью, если коротко сказать - то я не чего не понял.
Возможно у вас имеется какой-никакой опыт в настройке контроллеров WB для работы сразу в двух сетевых интерфейсах одновременно с разными DHCP (чтобы принимая запрос по eth1 он отвечал по eth1, а принимая запрос по eth0 он отвечал по eth0) то я полагаю, очень возможно, что я окажусь не один такой из тех, кто будет вам крайне признателен в том, что вы им поделитесь своим опытом. Я понимаю и вашу точку зрения, что спасение утопающих это их дело. Пожалуйста если это возможно то объясните для тупых что посмотреть и что исправить можно, я готов отключить модем wb-gsm-sim1 и оставить два интерфейса eh0 eth1 чтобы упростить задачу 
Попробовал. Нет возможности именно при получении по DHCP задавать маршруты штатно. А подъем дополнительных маршрутов внешними скриптами - ну, возможен, но это костыли по сути своей.
Если адреса выдаются именно по DHCP - тогда статические маршруты надо на DHCP сервере и описать, чтобы он их анонсировал вместе с дефолтным.
Например так:
0x00C0A87901180A7079C0A87901Задача обеспечения связности сетей - это работа системного (сетевого) администратора.
С точки зрения сети контроллер ничем не отличается от другого хоста.