teer

Ещё бродит мысль: а не нужно ли делать перезагрузку, чтобы применился введённый mls ipv6 vrf? В доке такого нет, но упоминается, что перезагрузка нужна для того, чтобы его выключить.

Думал и о том, что возможно не хватает TCAM-а под IPv6, и это даже вроде бы подтверждается: #show platform hardware capacity forwarding L2 Forwarding Resources MAC Table usage: Module Collisions Total Used %Used 5 0 98304 2228 2% VPN CAM usage: Total Used %Used 512 0 0% L3 Forwarding Resources Module FIB TCAM usage: Total Used %Used 5 72 bits (IPv4, MPLS, EoM) 196608 10356 5% 144 bits (IP mcast, IPv6) 32768 29703 91% detail: Protocol Used %Used IPv4 8307 4% MPLS 2049 1% EoM 0 0% IPv6 29471 90% IPv4 mcast 229 1% IPv6 mcast 3 1% Adjacency usage: Total Used %Used 1048576 2740 1% Forwarding engine load: Module pps peak-pps peak-time 5 2794023 6396218 15:44:35 KRSK Thu Mar 24 2016 (90% и 91% смутили). Но дока о перераспределении TCAM-а на 65xx/76xx (и для которого требуется перезагрузка) пишет, что при переполнении должна быть запись в лог. Да и судя по всему переполнения и не было: #sh mls cef exception status Current IPv4 FIB exception state = FALSE Current IPv6 FIB exception state = FALSE Current MPLS FIB exception state = FALSE Хотя в vrf-е всего несколько штук маршрутов, попробовал для опыта очистить TCAM для IPv6, потушив IPv6 BGP-пира. Утилизация TCAM под IPv6 упала до 1%, но безрезультатно.

Пока не читал про репликацию и утечки маршрутов, попробовал так: no interface Tunnel5 no interface Tunnel50 no interface Loopback2 ! interface GigabitEthernet1/45 description C-IPv6 no ip address no shutdown ipv6 address FE80::1 link-local ipv6 enable mls qos trust dscp storm-control broadcast level 5.00 ! interface GigabitEthernet2/44 description C-IPv6-vrf vrf forwarding C no ip address no shutdown ipv6 address FE80::2 link-local ipv6 enable mls qos trust dscp storm-control broadcast level 5.00 ! Толку опять же чуть. IPv6 ND не работает: #sh ipv6 nei gi1/45 IPv6 Address Age Link-layer Addr State Interface FE80::2 0 - INCMP Gi1/45

Хочу закинуть IPv6-префиксов из глобального контекста в vrf. Т.е. чтобы трафик уходил на хосты, подключенные в этот vrf и возвращался обратно в глобальный контекст по маршруту по умолчанию. Т.е. vrf здесь просто как "виртуальный роутер". Делаю аналогично тому, как настроено и работает для IPv4, но увы.

#sh ip cef summ IPv4 CEF is enabled for distributed and running VRF Default 87572 prefixes (87546/26 fwd/non-fwd) Table id 0x0 Database epoch: 2 (87572 entries at this epoch) #sh ipv6 cef summ IPv6 distributed CEF is enabled and running. VRF Default 29180 prefixes (29180/0 fwd/non-fwd) Table id 0x1E000000 Database epoch: 2 (29180 entries at this epoch) Видимо, где как. Бегает в такой конфигурации несколько пар туннелей с IPv4, гигабититы трафика, ничего не умирает, свичится аппаратно. Вопрос, что нужно для IPv6 или как можно это сделать. P.S.: про vrf route leaking и route replicate почитаю, но судя по тем верхам, что запомнились, это не то что нужно.

Да, "Работает и IPv6 в глобальном контексте" означает что пингается мир по IPv6 из глобального контекста. Хочется пробросить IPv6 в vrf. Ну и ipv6 unicast-routing не нужен для пингов между connected link-local адресами, насколько помню.

Пробовал уже "tunnel mode ipv6ip", "tunnel mode ipv6", от безысходности. Пишет, что пакеты будут коммутироваться программно, но всё равно не работает. Осталось только мысль MPLS поднимать между контекстами и пробовать "tunnel mode mpls", но как-то пока опасаюсь. Upd: "tunnel mode mpls" это скорее всего MPLS TE и не то. Но идея всё равно в поднятии MPLS через туннель между контекстами, где бегает IPv4.

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

Есть Cisco 7606 с RSP720-3C-GE/MSFC4/PFC3C и софтом c7600rsp72043-advipservicesk9-mz.122-33.SRE8.bin . Есть вот такого вида конфиг (выдержка): смысл в том, чтобы потом статическим маршрутом закинуть IPv6-сети в vrf, находящийся на этом же маршрутизаторе, для связи с ним организован GRE-туннель. C IPv4 такое получилось без проблем (другая пара туннелей), всё работает. Работает и IPv6 в глобальном контексте. А вот с IPv6 так не работает, нет между link-local адресами туннелей связи, пинги не ходят, соседи не дискаверятся, в логах пусто. Судя по счётчикам, трафик в vrf-контекст уходит и на него идут ответы, но что с ними происходит, непонятно. Прочитал все найденные цисковские доки, там везде вроде бы подразумевается, что GRE-туннель "из коробки" пропускает и IPv4 и IPv6 и никаких специальных телодвижений не требуется. Помогите снятся с ручника, что я делаю не так? Либо, если есть опыт, посоветуйте, как можно переделать, чтобы добиться желаемого.

Дали три штуки такого тайнственного железа как "Пингульник". При первичной настройке "на столе" проблем не возникло. Однако при включении первого же в работу мониторинг его упорно не видит. Сначала вроде бы как был ARP-ответ, но не было ответного трафика, потом и ARP пропал. При этот циске ядра (через которую подключен мониторинг), циске доступа (через которую подключаем пингульник) и всем другим хостам сегмента чудо-железка отвечает нормально, зашел, в конфиге у неё всё пучком. С другими адресами той же сети и того же влана на этом же коммутаторе доступа у мониторинга связность есть, без проблем. Т.е. L2 работает. Пробовал пока только менять ей MAC-адрес, переключать на другие порты коммутатора и переобжимать патч-корд с прямого на кросс (линк не подниматеся, судя по логу офисного коммутатора 10/half для неё это норма). Толку ноль. Подскажите, в какую сторону можно поковырять. P.S.: попробуем позже подключить остальные, может быть действительно дефективный образец попался.

Можно наверное строку запуска и не приводить. Надо дамп трафика смотреть. Я обнаруживал багу в VLC пару-тройку лет назад, заключается в том, что он игнорирует указанный TTL. К сожалению, тикет им не вешал. С тех пор VLC плавно скукоживается, так что, полагаю, бага до сих пор жива. Тогда делал костыль путём переписывания TTL iptables-ами.

Долго же я сюда не заходил... Отчитываюсь. Дело было в не в Микротике, а в: 1) Кривом дизайне OSPF-арий 2) Работе OSPF на мультиплексорах Netperformer SDM9230 (aka Verso), в результате которой все SDM9230 находящиеся в пирах у CCR почему-то иногда и ВНЕЗАПНО устанавливали в FIB маршрут на подсеть серверов не через один хоп (собственно, CCR), а чёрт-знает-куда, за спутниковые линки (откуда в принципе эта сетка прилететь не может). Из-за этого связь по ARP и в сегменте была, а вот с SRC IP серверов - нет. Итого, что сделано: 1) Влан со всеми SDM9230 вынесен на отдельный физический интерфейс (т.к. передёргивание MTU/L2MTU обрывает связь по всему линку). По итогу это оказалось необязательным. 2) Чтобы не переделывать глобально OSPF-кривизну сети, в сегменте с SDM9230 OSPF заменён на RIPv2-multicast Итого всё это стабильно работает уже почти месяц (22 дня аптайм CCR, до этого максимальный аптайм был 6 дней, типовой - 2 дня). За всё это время проблема проявилась только одна - цискари микротика пугаются :-)

Снова отвалились 6 из 13-ти OSPF-пиров для связности из серверной сети. Правда, *STP вчера зафильтровать не смог сходу, надо ковырять...

Ну, я у себя нагрузки не вижу - 2/3% загрузка каждого CPU. Днём. Ночью вообще почти по нулям. Основной объём трафика идёт не по туннелям.

Уже так и сделано, ICND1/2 читан :-) (стати, RouterID там исторически является IP-шником маршрутизатора из серверной сети). Ни один интерфейс не падает (PPTP не в счёт), т.к. не падает физический линк до свича. Ну и в любом случае, кратковременная потеря связности пока не сойдётся OSPF это несколько не то же самое что, "связи нет неопределённо долго, пока не перезагрузишь".