landy

Полностью согласен. Не получится, в vpn_20 нет маршрута по умолчанию. Более того, в каждом другом vrf (клиентский) шлюз разный.

Стандартную диагностику гну третий день, но, кажется, нашёл рабочий способ. Спасибо за участие :) Маршруты Connected между vrf проливались, но маршрут по умолчанию со шлюзом в другом vrf не появлялся. Покажу состояние "до решения": ip route vrf vpn_guest 0.0.0.0 0.0.0.0 192.168.20.12 ipv6 route vrf vpn_guest ::/0 fc00:20::12 test-cat# show ipv6 route vrf vpn_guest B fc00:20::/64 [20/0] via Vlan20%vpn_20, directly connected C fc00:86::/64 [0/0] via Vlan86, directly connected L fc00:86::1/128 [0/0] via Vlan86, receive L FF00::/8 [0/0] via Null0, receive test-cat# show ip route vrf vpn_guest S* 0.0.0.0/0 [1/0] via 192.168.20.12 192.168.20.0/24 is variably subnetted, 2 subnets, 2 masks B 192.168.20.0/24 is directly connected, 1d23h, Vlan20 L 192.168.20.9/32 is directly connected, Vlan20 192.168.86.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.86.0/24 is directly connected, Vlan86 L 192.168.86.1/32 is directly connected, Vlan86 S 192.168.101.0/24 is directly connected, Null0 Т.е. в ipv4 статический маршрут добавился, а в ipv6 железо почему-то решило, что next-hop неизвестно где. Решил так: no ipv6 route vrf vpn_guest ::/0 fc00:20::12 ipv6 route vrf vpn_guest ::/0 fc00:20::12 nexthop-vrf vpn_20 test-cat#show ipv6 route vrf vpn_guest S ::/0 [1/0] via fc00:20::253%vpn_20 B fc00:20::/64 [20/0] via Vlan20%vpn_20, directly connected Пойду посмотрю, где ещё сюрпризы есть...

Из посторонних команд только ipv6 unicast-routing? Странное ощущение, что я не нашёл какой-то волшебной команды вроде mls ipv6 vrf (её нет на этом свиче).

Всем добрый день. По ряду причин в локальной сети использую цискин vrf lite в ipv4. Условно vpn_20 для связи между маршрутизаторами и vpn_что-то для прочих сетей. Маршруты успешно проливаются с помощью bgp. На тестовой железке миграция с ip vrf к vrf definition прошла успешно, но никак не могу завести в этом address-family ipv6 - маршруты протекать не хотят. У кого-то есть опыт настройки этого? Рабочая часть конфига для ipv4 ниже, нужен аналог для ipv6. Железо Cisco 3650, ipservices, 16.3.2. vrf definition vpn_20 rd 100:20 route-target export 100:20 route-target import 100:12 ! address-family ipv4 exit-address-family ! vrf definition vpn_guest rd 100:12 route-target export 100:12 route-target import 100:20 ! address-family ipv4 exit-address-family interface Vlan20 description Routing vrf forwarding vpn_20 ip address 192.168.20.9 255.255.255.0 ! interface Vlan86 description Test vrf forwarding vpn_guest ip address 192.168.86.1 255.255.255.0 ! router bgp 65535 bgp log-neighbor-changes ! address-family ipv4 vrf vpn_20 redistribute connected exit-address-family ! address-family ipv4 vrf vpn_guest redistribute connected exit-address-family

Пардоньте, уточню - у меня все шнурки с тегированным трафиком подписаны как UPLINK, с нетегированным - просто как LINK. Хочется-не хочется, а всевозможную непредсказуемую динамику я предпочитаю зарубать руками. Я админ на предприятии, а не у провайдера, т.е. с другой стороны подключения я тоже делаю duplex full. В этом конкретном примере на другом конце шнурка висит дешёвый dlink со vlan'ами, в который уже непосредственно втыкаются пользователи. port-security, к сожалению, неприменим. ACL - заблокировать ответы dhcp-сервера из-за порта? Можно поподробнее про switchport block unicast? Оно вообще весь dlf зарубит?

Да-да, я уже много раз видел и читал про "обязательно включите DTP и PVST на портах" в официальных цискиных мануалах, но в реальной жизни на портах коммутатора, смотрящих к конечным пользователям, многое приходится подкручивать. А как вы "бронируете" свои циски? Мой базовый конфиг порта выглядит примерно так: interface GigabitEthernet0/1 description UPLINK TO SOMEWHERE switchport trunk encapsulation dot1q switchport trunk native vlan 4092 switchport trunk allowed vlan 1,2,3 switchport mode trunk switchport nonegotiate logging event link-status duplex full storm-control multicast level 64 16 storm-control broadcast level 64 16 storm-control action trap no cdp enable spanning-tree portfast trunk spanning-tree bpdufilter enable

Был опыт настройки схожего на 5510. Включил 3DES, поднял оба канала, настроил переключение маршрута по умолчанию через sla и какой-то узел за пределами сети провайдера, резервная точка в тоннеле настроилась простым указанием двух адресов в crypto map External_map 110 set peer 1.2.3.4 5.6.7.8. Аналогично с другой стороны.

Есть коммутатор WS-C3560G-24TS, в него приходит несколько оптических портов (1Gig), на нём самом крутится маршрутизация (sdm desktop default), vrf lite (bgp), ospf. Хочется ему на замену купить WS-C3650-24TD-E, заменить один из оптических портов на 10G (SFP-10G-LR-S=) и включить ipv6. Интересно два момента. 1. Сумеет ли эта железка сделать vrf lite для ipv6? 2. Хватит ли у неё здоровья под такой нагрузкой жить и работать?

Такую проблему на 3750G лечили переносом маршрутящих интерфейсов на другое железо. От ситуации зависит. В routing меньше общее количество ipv4 unicast routes, чем в default, но больше количество непосредственно indirect ipv4 routes. Show sdm prefer ... в помощь.

ollsanek NiTr0 Всё оказалось проще - у провайдера были свои прихотливые настройки в плане доверия анонсам из интернета и от клиентов. Месяц мучал провайдера - получил перенастроенный local preference. Коммуните через него как-то своенравно ходили. В принципе, схема действительно рабочая. Сейчас буду ловить тараканов в плане доступа изнутри - у меня тут своё тяжелое наследство. Возможно, по итогам даже рожу статью :)

С snmp и определением петель нормально справляется?

Косяк нечаянно нагрянул. Если трафик порождается откуда-то из сетей резервного провайдера, то он очевидным образом идёт через роутер 2, а обратно через 1, т.е. рушится внутри. Попробую добавить к схеме conntrackd...

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

Анонсировать DMZ как connected - не вариант, об этом уже упомянули. BFD - помогло бы ускорить обсыхание BGP, но мне по сути надо рвать подключение eBGP при разрыве сессии iBGP. Мимо. Анонсировать DMZ от третьего лица. Предположим между роутерами 1-2 и DMZ я ставлю роутеры 3 и 4 (чтобы иметь резервный шлюз из DMZ), через которые кручу DMZ. 3 и 4 дружу по какому-нибудь протоколу с 1 и 2. Пусть это будет ospf, между 1-2-3-4 один VLAN, все динамично друг с другом дружатся. На 1 и 2 редистрибуцию из ospf, играться с метриками... На бумаге выглядит реализуемым, но громоздким. Своя идея - на роутере 1 запускать раз в 5 секунд пинговалку до 2 через dmz-интерфейс. Если связность пропала, скриптом рвать ebgp с провайдером (вариант - убирать dmz из анонсов). 2 подхватывает шлюз, по ebgp всем всё рассказывает, наступает идиллия до момента, пока 1 не вернётся в строй. Когда связность восстанавливается, роль шлюза возвращается на 1, а скрипт возвращает ebgp к исходному состоянию. Выглядит реализуемым, несложным, но попахивает колхозом :) Всем спасибо за участие, будут ещё комментарии и предложения? PS. Три сообщения в сутки - это сильно.

Бомба :D у меня были мысли через хитрые каналы скриптами довыключать, но вот так прямо по питанию... Если серьезно, то решение выглядит очень драконовским, хотя проблему решает. Можно поподробнее идею про железку в dmz? Перетащить ebgp к провайдерам на отдельную железку, живущую внутри dmz?

Есть два роутера (CentOS), каждый подключен к отдельному провайдеру и считает его шлюзом по умолчанию. Между роутерами есть iBGP, между каждым роутером и его провайдером есть eBGP. Есть отдельная сеть /24 на роль DMZ. Дал каждому роутеру по интерфейсу в эту сеть, на них поднял vrrp (через keepalived), роутер 1 выдаёт себя за шлюз, роутер 2 его страхует. При таком раскладе весь трафик из DMZ уходит через роутер 1, пока он жив. Если роутер 1 внезапно погибает, роутер 2 подхватывает роль шлюза dmz, а интернет узнаёт о переменах через bgp. Работает, годится. Есть одно "но" - если у роутера 1 по какой-то причине теряется связь с dmz, сам он анонсировать себя по bgp как маршрут к dmz не перестаёт. При таком раскладе трафик из dmz выходит через роутер 2, а возвращается через роутер 1, где благополучно дохнет. Вопрос - как следует разбираться с такой ситуацией? Есть какие-то решения на уровне дизайна, кроме хитрой системы скриптовых костылей?

OSPF отлично запускается в пределах vrf. Если понадобится проливать маршруты между vrf, придётся подключить bgp (у меня так и не вышло сделать это через ospf).