throughtheether

На этом устройстве, насколько я понял, можно запустить openWRT, а на openWRT можно писать разные скрипты, вроде такого. Вам остается поменять парсинг лога на какое-то взаимодействие с удаленным сервером (при помощи wget или curl).

Спасибо, что "призвали" в топик, выражу свое мнение.

Вы привели ссылку

Вот еще одна карта habrahabr.ru/company/cjdns/blog/198428/.

Если честно, мне представляется, что эта ссылка не относится к вашей проблеме. Статья, доступная по ссылке, насколько понял, описывает некую одноранговую сеть на 3 выше уровнях модели OSI, грубо говоря, свой отдельный интернет, с отсутствием цензуры и криптоанархизмом. Вам, теоретически, могла бы пригодиться одноранговая сеть на уровнях 1-2 модели OSI, то есть сеть из Wi-Fi-трансиверов, предоставляющая обычную IP-связность и доступ в интернет.

Однако, в вашем случае, при наличии соответствующей возможности, я бы выбрал кабельные решения (волокно до дома) и лишь в каких-то особых случаях использовал Wi-Fi. Беспроводные решения привносят довольно много потенциальных проблем, а в случае одноранговой (mesh) сети полезная пропускная способность будет делиться между абонентами, в результате итоговое преимущество такого подхода неясно.

Физический интерфейс провайдера - один порт Ethernet.

На месте провайдера было бы уместно, на мой взгляд, использовать unnumbered интерфейс и vlan на пользователя. Тогда бы с вашей стороны любого коммутатора хватило.

Использование только коммутатора без роутера чревато тем, что на стороне провайдера на мой коммутатор срабатывает бродкаст шторм и блокировка.

Статические ARP-записи и фильтры широковещательного/многоадресного трафика вам могут помочь, хотя такой подход снизит удобство управления сетью.

Собрал топологию на GNS3:

По первому вопросу:

Будет ли клиент пинговать другого клиента с адресом 10.45.18.194 и почему?

Да, пинги проходят:

ClientA#ping 10.45.18.194 repeat 10

Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.45.18.194, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 20/34/48 ms

Теперь самое интересное. 10.45.18.194 отсутствует в таблице маршрутизации Клиента А, поэтому icmp-запросы до 10.45.18.194 инкапсулируются в Ethernet-фреймы с адресом назначения маршрутизатора провайдера (00ff.ffff.ffff). Маршрутизатор провайдера при этом декапсулирует IP-пакет с ICMP-запросом, инкапсулирует его в Ethernet-фрейм со своим адресом (00ff.ffff.ffff) в качестве адреса источника и адресом Клиента Б (00bb.bbbb.bbbb) в качестве адреса назначения (это подтверждается дампами трафика). Клиент Б, получив ICMP-запрос, формирует ответ, отсылает ARP-запрос для определения MAC-адреса Клиента А (т.к. IP-адрес Клиента А находится в той же "подсети", что и адрес Клиента Б), и отсылает ответ непосредственно ему.

В отличие от обычной ситуации (когда при отстутствии ARP-записей теряются 1-2 пинга), в данном случае генерируется 3 ARP-запроса (Клиент А определяет MAC-адрес маршрутизатора провайдера, маршрутизатор провайдера определяет MAC-адрес Клиента Б, Клиент Б определяет MAC-адрес Клиента А), соответственно первоначально теряются 3 пинга.

Клиент на маршрутизаторе меняет конфигурацию интерфейса на такую:
Interface e0/0
Ip address 10.45.18.15 255.255.255.128
Ip address 10.45.19.15 255.255.255.0 sec
No shutdown
!
Будет ли адрес 10.45.19.15 присутствовать в ARP таблице маршрутизатора провайдера?

Во-первых, если просто назначить адрес и не генерировать никаких ARP-запросов, то, естественно, маршрутизатор провайдера просто не узнает о наличии такого адреса. Во-вторых, если сгенерировать, например, gratuitous arp reply (деактивировав и снова активировав интерфейс, shutdown, no shutdown), маршрутизатор провайдера получит ARP-пакет (т.к. ARP распространяется широковещательно), но вполне может не принять его во внимание, учитывая отсутствие маршрута до 10.45.19.0/24 через входящий интерфейс:

ISP#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.45.18.5              -   00ff.ffff.ffff  ARPA   FastEthernet0/0
Internet  10.45.18.15            24   00aa.aaaa.aaaa  ARPA   FastEthernet0/0
Internet  10.45.18.194           22   00bb.bbbb.bbbb  ARPA   FastEthernet0/0
ISP#
*Mar  1 01:24:18.735: IP ARP: rcvd rep src 10.45.18.15 00aa.aaaa.aaaa, dst 10.45.18.15 FastEthernet0/0
*Mar  1 01:24:18.739: IP ARP rep filtered src 10.45.19.15 00aa.aaaa.aaaa, dst 10.45.19.15 ffff.ffff.ffff wrong cable, interface FastEthernet0/0
*Mar  1 01:24:18.739: IP ARP: rcvd rep src 10.45.18.15 00aa.aaaa.aaaa, dst 10.45.18.15 FastEthernet0/0
*Mar  1 01:24:18.739: IP ARP rep filtered src 10.45.19.15 00aa.aaaa.aaaa, dst 10.45.19.15 ffff.ffff.ffff wrong cable, interface FastEthernet0/0
ISP#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.45.18.5              -   00ff.ffff.ffff  ARPA   FastEthernet0/0
Internet  10.45.18.15             0   00aa.aaaa.aaaa  ARPA   FastEthernet0/0
Internet  10.45.18.194           23   00bb.bbbb.bbbb  ARPA   FastEthernet0/0

Таким образом, экспериментальные ответы на ваши вопросы таковы:
1) да, пинги проходят
2) нет, ARP-записи не будет

Я лично полагаю, что практика (хотя бы такая) - лучший критерий истины. Другое дело, что тот, кто будет проверять ваши ответы, может считать по-другому.

flooding

Да, при отправке фрейма с MAC-адресом назначения, не поместившимся в FDB (их всего примерно 100), фрейм будет скопирован во все порты (кроме того, на который он первоначально пришел).

forwarding

Да, при отправке фрейма с MAC-адресом назначения, находящемся в FDB, фрейм будет направлен только в соответствующий порт.

filtering

Не уверен, что именно подразумевается под этим термином. Если некая ACL-фильтрация, то ей в данном контексте проявиться негде. С другой стороны, коммутатор иногда называют фильтрующим мостом (FDB, между прочим, это filtering database), но и в этом смысле я не вижу причин для фильтрации (т.е. ни специальной фильтрующей записи в FDB, ни получения фрейма с MAC-адресом назначения A на порт, с которым этот адрес ассоциирован).

В любом случае, вам лучше проконсультироваться с учебными материалами.

вот я хочу узнать, что же ждать от него?

На мой взгляд, представляется конструктивным выделить функциональность, которая потребуется от устройства в рабочем режиме (в "продакшене") и затем каждый пункт протестировать отдельно. В частности, стоит проверить работу xSTP и его нюансов (BPDU guard и т.д.), ARP Inspection, фильтрации по MAC-адресам, ограничения широковещательного/многоадресного трафика (storm control), DHCP snooping, IGMP (если планируется использовать). Для этого может потребоваться собрать тестовый стенд и сгенерировать необходимый трафик (под linux рекомендую scapy для формирования специфичных пакетов/фреймов и hping для генерации интенсивного трафика).

Не вижу особого смысла в попытках полностью утилизировать ресурсы коммутационной матрицы ("фабрики"). Для этого потребуется задействовать все порты коммутатора. Etherchannel здесь, на мой взгляд, вряд ли сильно поможет, учитывая поддерживаемый коммутатором режим разделения трафика по линкам внутри etherchannel ("Поддержка балансировки по destination-MAC", отсюда).

Ищется универсальное средство по сбору конфигов(как + - со сравнением конфигов)

rancid. Насколько знаю, есть модули для снятия конфигурации hp и dlink. Но будьте готовы к тому, что "универсальное" средство придется дорабатывать под ваши нужды.

Можно ли подключить к маршрутизаторы 5 коммутаторов,а каждому коммутатору подключены 12 пк?

Можно, если хватит портов. Если правильно настроить (и оборудование поддерживает необходимые технологии), то еще и работать будет.

Что такое vlan?

Технология (их несколько, на самом деле), позволяющая, с точки зрения перенаправления (форвардинга) фреймов, логически разделить один коммутатор на несколько "виртуальных" коммутаторов с тем, чтобы трафик в разных VLAN ("виртуальных коммутаторах") между собой не взаимодействовал. Наиболее распространенная реализация - port-based vlan (разделение коммутатора на виртуальные) и 802.1q trunking (трафик между коммутаторами).

Можно ли подключить два маршрутизатора находящиеся на расст. 1км с помощью оптики если у маршрутизатора нет интерфейся для оптики а только etherenet? т.е ему нужен(маршрутизаторы) медиаконвертор?

Да, если есть пара подходящих медиаконвертеров. Есть еще вариант использовать атмосферную оптику, но лучше все же использовать оптоволокно.

Есть ли какая-нибудь официальная документация

Желательно на русском языке.

Сильно сомневаюсь.

ресурс по управлению данным оборудованием?

ссылка.

Падение линка не падение интерфейса. Подскажите как можно выкрутиться не прибегая к протоколам BGP.

Или самому организовывать добавление/удаление маршрутов в зависимости от "доступности" (ping и прочая) противоположного конца тоннеля, или использовать динамическую маршрутизацию через туннельные интерфейсы (реализации RIPv2, если не ошибаюсь, есть почти под каждую из популярных ОС).

Точнее можно будет ответить после того, как вы предоставите схему организации сети.
UPD:

Очень краткая схема в первом комментарии выше.

Если я правильно понял, то можно (нужно?) изменять маршрут по умолчанию (т.е. маршрутизировать трафик на OPENVPNSERVER1 или OPENVPNSERVER2) на 3750 в зависимости от работоспособности тоннеля?

Когда трава была зеленее я видел использованиe route map в зависимости от пинга, но не запомнил и информации сейчас нет.

На мой взгляд, вам подойдет решение в виде статической маршрутизации вкупе с ip sla tracking. См. раздел Резервирование.
UPD2:

К сожалению со второй стороны также нужно отправлять пакеты, в свою очередь выбирая интерфейс. А там у нас чисто линуксовое решение.

Я полагал, что хотя бы с одной стороны маршруты исчезают при нарушении работоспособности туннеля. Если нет, то остается RIPv2 (на 3 серверах с openvpn и на устройстве cisco).

На мой взгляд, сеть довольно проста, требования не самые трудновыполнимые, но выбрать лучше 3550.
Плюсы:
- когда ваша сеть вырастет из одного L2-сегмента, 3550 можно будет переконфигурировать (используя его L3-возможности)
- больше "кнопочек и рычажков" - более разнообразный опыт настройки для вас

Единственное, если нужны гигабитные аплинки для связи между помещениями (в чем я сомневаюсь), то потребуется докупить модули.

По поводу HP ProCurve, мне запомнился менее удобный по сравнению с cisco/juniper cli-интерфейс и странная терминология (то, что я привык называть portchannel/etherchannel/aggregated ethernet, в терминах HP называется Trunk).

На компьютере не работает интернет, до тех пор, пока не запустишь команду "ping 192.168.5.16". Затем через какое-то время, минут 15, снова пропадает. Тут спасает только "ping 192.168.5.16 -t".

Одна из возможных причин - наличие в L2-домене хоста с IP-адресом, совпадающим с вашим или целенаправленная подделка arp-ответов. Стоит пронаблюдать состояние arp-таблицы на маршрутизаторе. Кроме того, можно самостоятельно (hping, scapy) послать arp-запрос с вашим ipv4-адресом в качестве искомого, посмотреть, кто откликнется.