Strabbo

Итог один и тот же, 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, так вы можете указать время когда будет можно или нельзя заходить на конкретные сайты.

В вашем случае, я бы остановился на active-backup от STP. С quagga тоже можно сделать, но там мороки много если на сервере много IP будет, то придется часто переделывать конфиг на квагге, можно и редистрибюцию настроить, но если будет кейс где не надо редистрибьютить все IP, а надо только конкретные и тд. Или на одном физ сервере будут много виртуалок с другими подсетями или же часто будут меняться или добавляться, то придется часто возиться с квагой. Если траффик не больше 1Г то лучше сделать active-backup. В идале надо бы поставить свичи, которые умеют работать в стеке и от стека уже тянуть агрегированые каналы до сервера.

Если есть возможность докупить карты, то я бы докупил и связал бы их со свичами (который выполняют роль HSRP), если у карточек по 2 порта то с двух роутеров по 2 линка на каждый свич, можно сделать из ник L3 etherchannel, а с третьего роутера по одному линку на каждый свич и тоже L3 p2p. Если же нету возможности докупить карточки и есть свободные порты на свичах, то можно сделать тоже самое, только поднять L2 etherchannel-ы и перенести аплинки других сейтей с роутера на свичи и на роутере на сабинтерфейсах поднять роутинг с провайдерами BGP