Strabbo

Я понимаю, что при нерабочем канале от 7750 к 7705 Hello пакет приходит, но как 7705 отправляет ответный hello, если он должен инкапсулироваться в ip, а потом в ethernet, но маршрутизатор не знает на какой mac-адрес отправлять ответ?

Насколько я помню OSPF использует свой протокол, которому не нужен ARP, работает по дефолту он по мультикасту, там не надо знать мак адреса участников, пакет получать все кто будет слушать группу.

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

Во многих случаях на Exstart зависает, когда MTU на обоих концах разные. Можно попробовать убрать проверку MTU. В остальных случаях надо смотреть дебаг.

PS. Если платфора позволяет то настройте связку BFD + OSPF, она должна лучше отрабатывать переключение между линками во время проблем на одном из линков.

Итог один и тот же, VLAN блокируются с 2 сторон, не выходит сделать полный доступ с 33 к 30 и чтобы небыло у 30 к 33.

На 3810m никак. Ставьте фаервол, на нём можно сделать то что вам нужно

Если они в одной сети, то на хосте в качестве шлюза по умолчанию пропишите айпи pfsense-а.

EOIP tunnel должен вам подойти

Всё зависит от ваших хотелок и имеющегося оборудования.
1. Какие у вас свичи?
2. Чего вы хотите добиться прописывая ip на свичах, а не на роутерах?
3. Отказаустойчивость обеспечивается не до клиента, а до свича протоколами маршрутизации. Надо связать свич с двумя другими свичами/роутерами. Метрики это не про отказоустойчивость.
4. Если IP серые, то можете хоть /31 прописывать для каждого клиента если оборудование позволяет. Если белые, то всё зависит от ваших хотелок. Можно например всех в одну сеть закинуть, но потом если вам понадобится фильтровать траффик на свиче для каждого клиента отдельно, то это будет проблематично, потому чо коммутатор это не фаирволл. Если делать ACL для каждого клиента отдельно, то может переполнится TCAM(всё зависит от самого фильтра и железки), если переполнится TCAM, то пакеты пойдут в CPU и он может загнутся. + если прописать IP на свиче, то надо будет городить более сложный Control Plane Policy, чем для L2 свича.
5. У меня больше вопросов, чем ответов. Сперва опеделите для себя зачем это вам нужно. Если есть конкретная задача, то опишите её. Если хотите сделать всё красиво для серверов, то смотрите дизайн топологий для датацентров (VPC, VXLAN)

Trunk - магистральный порт, который позволяет создавать магистральное соединение между промежуточными сетевыми устройствами (коммутаторами).

Нет, термин trunk никак не связан с магистралями и магистральными линками. Trunk - режим порта, при котором он может отправлять тегированые пакеты. Вы можете использовать транк в сторону другого роутера, комутатора, компьютера, сервера и так далее.

Т.е. гибридные порты могут работать как в режиме портов доступа, т.е. принимать нетегированный трафик, так и в режиме приёма тегированного трафика.

Да.

Мне казалось, что коммутатор, принимая от компьютера нетегированный трафик (с гибридного порта), затем либо тегирует его (если этот трафик не из Native VLAN), либо передаёт его дальше нетегированным (если это Native VLAN), а телефон уже передаёт тегированный трафик. Это так?

Всё зависит от того, что надо будет делать дальше с трафиком.

switchport mode hybrid
switchport hybrid pvid 33
switchport hybrid allowed vlan add 33 untagged
switchport hybrid allowed vlan add 34 tagged

В вашем случае если пакет пришел не тегированый, он попадет во влан 33, если надо этот пакет послать на соседний порт с таким же конфигом, то его свич тегировать не будет и прямо отправит так как есть. Если же например этот пакет надо будет отправить на другой порт, который работает в режиме транк (например на другой комутатор или на другой порт этого же свича, только с другим конфигом(транком)), то ваш пакет будет передаваться уже тегированым.

switchport hybrid allowed vlan add 34 tagged

Разрешает принять пакет с вланом 34 ну и в обратную сторону, если надо будет оправить пакет на этот порт с этим вланом, то он будет тегированым. Если надо будет отправить пакет в другое место, то всё уже зависит от конфига другого порта.
Вы можете принять пакет не тегированым, повесить на него тег и отправить уже в другое место тегированым.
Если вы учитесть, то используйте wireshark на всех портах, там будет видно как и и с какими тегами идут пакеты.
Всё зависит от конкретного конфига.
Если всё это вы затеяли ради ради того, чтобы подключить к одному потрту телефон + компьютер, то для этого у cisco есть voice vlan, который легко настраивается.

Если не получается сделать с помощью радиус атрибутов, то можно попробовать локальный PBR или же можно использовать VRF. Серый пул в отдельный VRF, у него в таблице маршрутизации будут только IP платежных сайтов и Default на linux маршрутизатор, который будет редиректить на страницу оплаты.

Достаточно одного роутера в качестве облака. К нему бодут подключаться ваши клиенты. Нету смысла строить сеть провайдера из 4-5 устройвст. Не помню как там в пакет трейсере, но в GNS3 и eve-ng можно прокинуть мост в вашу локальную сеть, а оттуда уже доступ в интернет, таким образом у вас будет полноценное облако. Берете один роутер в качестве устройства провайдера, подключаете его к мосту, а дальше уже ваши роутеры к роутеру провайдера.

Сначала надо узнать для себя зачем вам изучать циску. Если вы начинаете свою карьеру сетевика и вам просто нужно научиться конфигить циску или же нужно только CCNA, то тратиться на железо не стоит. Если же вы преследуете сертификаты и на CCNA не остановитесь, то всё будет зависеть от того какой вы человек. Например в CCNP желательно много делать практических работ, нужно хорошо освоится в CLI и знать каждую команду, которая вам понадобиться во время изучения. Я, например, после пары часов за GNS3 или юнетлаб быстро утомляюсь и мне становится скучно, а вот с железом всё иначе, интерес пропадает намного медленнее, чем в виртуальной среде. Так что всё зависит от вас. Также есть темы, которые в виртуальной среде не поднимишь. Например такие фичи как stacking, UDLD, SDM templates, POE, многое из STP + STP у меня часто глючил в юнетлабе, а SNMP там вообще не работал и еще много таких вещей, щас просто все не вспомнить. CCNA сможете освоить и сдать экзамен даже с пакет трейсером, хотя и там много багов, в GNS3 поменьше. На вашем месте я бы поступил так:
1. Начал бы учить используя GNS3
2. Если почувствуете, что виртуализация это не для вас, то тогда можно и лабу собрать.

P.S. Когда я говорил, что надо знать каждую команду, то я имел ввиду именно это. Многие говорят, что каждую команду знать не нужно, но если вы будете сдавать экзамен, то вам будут встречаться команды типа: какой командой надо сделать ту или иную вещь, какого куска конфига не хватает для того, чтобы всё заработало и так далее. Причем это вопросы без симлетов и лаб. там не зайдешь на устройство и не проверишь что к чему.

Если роутеры подключены напрямую, то можно и без тунеля. Если они в сети интернет и связываются друг с другом с помощью ipsec туннеля то всё будет зависить от типа туннеля.
Дело в том, что RIPv2 и OSPF используют мультикаст, а простой site2site ipsec вроде не поддерживает мультикаст (насколько я помню, поправьте если я не прав.) Вам понадобиться поднять IPsec, ав нём прокинуть GRE или IPIP туннель и в них уже гонять динамическую маршрутизацию. RIP и OSPF включаются просто, просто включите их на всех интерфейсах, которые будут маршрутизироваться + тунельные интерфейсы

Если надо заблокировать сайты, а не URL-ы, то можно и без прокси. Блокировать по днс regexp или по regexp искать SNI. микротик всё это умеет. Микротик умеет time based ACL, так вы можете указать время когда будет можно или нельзя заходить на конкретные сайты.