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 это несколько не то же самое что, "связи нет неопределённо долго, пока не перезагрузишь".

Как вариант попробуйте зафильтровать BPDU в сторону CCR. Из нашей практики были проблемы если на бриджах CCR был включен *STP. Спасибо, попробую... Странно, как раз после обновления на 6.33 появились TX Drops на dot1q-интерфейсе серверов (где мониторинг).

На самом CCR один бридж без портов и без *STP, используется как Loopback-интерфейс. На свичах проблемного ethernet-сегмента дикая солянка из PVST+, PVRSTP+, CST, MST, каталистов, длинков и безымянных неуправляшек. На умном железе мониторю BRIDGE-MIB, блокировок там не замечено.

Ан нет, дело не в собственно dot1q-интерфейсе. Только сейчас проверил потери пакетов по всем хостам в этом ethernet-сегменте. Потери были только до 8-ми хостов из 13 железок данного типа (все они являются OSPF-пирами). Ещё полтора десятка разных железок пинговалось штатно.

Спустя пять дней аптайма, внезапно, снова накатило. Что интересно, оказалось, что проблемная сеть на dot1q пингуется с CCR-а только с SRC-адреса из этой сети. С SRC-адресов других сетей (откуда идут сервера мониторинга, которые, собственно, и поднимают тревогу) маршрутизатору тоже не отвечают. Как и обсуждалось, в отсутствии отладки ARP, просто сравниваю ARP-таблицу в нормальной и проблемной ситуации и вижу: teer@teer ~ $diff -U0 arp_good.txt arp_BAD.txt |grep 192.168.127. -IP-MIB::ipNetToMediaPhysAddress.28.192.168.127.188 = STRING: 0:20:a:b0:b4:4e +IP-MIB::ipNetToMediaPhysAddress.28.192.168.127.188 = STRING: 0:20:a:b0:cd:9f +IP-MIB::ipNetToMediaPhysAddress.28.192.168.127.202 = STRING: 0:20:a:b0:b3:e0 teer@teer ~ $egrep 0:20:a:b0:cd:9f arp_good.txt IP-MIB::ipNetToMediaPhysAddress.28.192.168.127.217 = STRING: 0:20:a:b0:cd:9f teer@teer ~ $egrep 0:20:a:b0:cd:9f arp_BAD.txt IP-MIB::ipNetToMediaPhysAddress.28.192.168.127.188 = STRING: 0:20:a:b0:cd:9f IP-MIB::ipNetToMediaPhysAddress.28.192.168.127.217 = STRING: 0:20:a:b0:cd:9f Т.е. один из OSPF-пиров на проблемном интерфейсе сменил (!) MAC-адрес, устроив конфликт (саму железку я проверил, она ни сном ни духом). В логе в момент возникновения проблемы тоже не пусто: Сравнение списка и состояния OSPF-пиров подтверждает, что DR/BDR в сегменте поменялись. Ещё раз посмотрел торчем, подтвердил, что входящие пинги приходят на CCR, но в проблемный сегмент не улетают. Далее т.к. не было больше идей, обновился до 6.33. Помогло, после ребута связь сразу же появилась. MAC-адрес у 192.168.127.188 вернулся старый. Пинг с CCR с src-ip мониторинга пошел. Получается, в данном конкретном случае, Saab95 прав - похоже, что-то нехорошее происходит в ethernet-сегменте, на L2. Другое дело, что это не повод так позорно глючить (циска же работала стабильно). Жалко, что /tool netwatch не поддерживает указание src-ip, хоть автоматизировать костылелестроение. Upd: проверил, количество роутов не уменьшалось. Наоборот, непосредственно перед ребутом было рекордное 452 штуки. P.S.: есть и хорошие стороны. Реально начала работать галка use-encryption=required в PPP-профиле. Т.е. клиенты без поддержки шифрования перестали подключаться. Плюс, пока не видел случая, чтобы было Encryption got out of sync - disabling на ходу. Теперь хорошо бы ещё аналог цисковских source-ip, чтобы можно было разные профили PPP привязывать к разным входящим интерфейсам.

Торчем я смотрел пару раз. Не уверен, что так было во всех случаях, но не видел исходящего трафика на dot1q-сабинтерфейсе. Кстати, до текущей перезагрузки, видел раз торчем что не проходил ответ из-за данного сабинтерфейса, причём только на один IP-адрес (с другого адреса той же подсети всё работало). Сейчас уже не воспроизводится. Так что до коммутаторов даже дело не доходит. Но наверное действительно стОйт посмотреть за ARP-таблицей, может там что-то меняется. И ARP попробовать поотлаживать. Upd: Упс, а на микротыке нет отладки ARP :-(

Пробовал, просто не все шаманские пляски описал. Мультикаст проходит (CDP/MNDP/OSPF).

Потому что циска достала своими мелкими глюками, а тут ещё потребовалась именно такая модель в другом месте. Ну и учитывая (небольшой) положительный опыт с микротыком, подумал что под такую небольшую и некритичную нагрузку (управление/мониторинг) CCR будет в самый раз (что сложно налажать в такой простой конфигурации). Финдиректор был доволен после ASR-ров :-) А что вообще из "нормального" можно поставить под такое дело? ASR не хочется, ибо так понимаю там только L2TP+IPsec. Ну и цена, конечно. Если вообще привезут.

Есть CCR1009-8G-1S-1S+, софт теперь уже последний текущий, 6.32.3. Конфиг довольно объёмный, так что попробую в общем описать ситуацию. Занят один гигабитник, через который приходит нетегированный трафик и несколько десятков dot1q-сабинтерфейсов. Итого около сотни connected-сетей (несколько сотен ARP-записей). Запущен PPTP-сервер, активных туннелей в среднем три-четыре десятка (с MPPE). Одна PCQ-очередь. Запущен OSPF, около двух десятков соседей. Из соображений безопасности весь трафик проходит через IP firewall (pptp/vlans), там фильтруется (в основном по address-list-ам) и чуть-чуть натится. Несколько десятков статических маршрутов плюс по OSPF прилетает две с лишним сотни, итого не более полутысячи записей в FIB. Включен экспорт Netflow. LCD выключен. Трафика не более 30Mbps в дуплексе, загрузка CPU 2-4%. Всё настроено, всё работает. Ошибок на физике или в логе не видно (если не считать надоедливых OSPF Discarding packet: locally originated). НО есть проблемы. Основная такая: в непредсказуемый момент времени перестаёт форвардиться трафик через один из dot1q-интерфейсов (за ним дюжина OSPF neighbour-ов с кучей анонсов роутов, для них на интефейсе слегка уменьшен MTU). Т.е. теряется связь со всеми сетями за данным сабинтерфейсом, в т.ч. прилетевшие по OSPF. Что интересно: в момент возникновения проблемы с самого CCR всё отвечает, всё пингуется, но с других устройств не откликаются даже устройства с сегменте этого интерфейса. Таблица маршрутизации при этом не меняется, /ip route print where X.X.X.X in dst-address по прежднему показывают 1) дефаулт роут 2) blackhole supernet и 3) connected. Выключение всех правил /ip firewall (filter/nat/mangle) не помогает. Передёргивание OSPF-интерфейса или OSPF-инстанса не помогает. Помогает тупая перезагрузка. Хреново, что у самого CCR всё доступно, так что даже netwatch не настроишь. И как такое отлаживать? Вторая проблема в том, что OSPF-роуты начинают работать, внезапно, только после перезагрузки (хотя присутствуют в FIB). Но это уж мелочь. P.S.: пользователь на железке один, вмешательство исключено. P.P.S.: это замена Cisco7201, она с аналогичным конфигом работала стабильно, тоже не особо напрягаясь.

Тоже так подумал, поэтому первым делом сделал clear arp, плюс поменял MAC-адрес на сервере 192.168.110.47 (ну и проверил заодно что это случайно не L2-multicast MAC-адрес), не повлияло никак. Попробую посмотреть в сторону RPF, но навскидку в debug ip cef drops rpf - пусто.

Есть Cisco 7201 (c7200p-adventerprisek9-mz.152-4.M6.bin)у с кучкой dot1.q-интерфейсов, VPDN (PPTP, MPPE) и немного NetFlow. Столкнулся с такой загадкой: почему-то железка не форвардит трафик между подсетью 192.168.142.40/29 на интерфейсе Gi0/0.147 и некоторыми хостами: #sh ip cache flow | i SrcIf|192.168.142.44 SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts Gi0/0.147 192.168.142.44 Null 192.168.200.7 01 0000 0000 165 Gi0/0.110 192.168.110.47 Gi0/0.147 192.168.142.44 01 0000 0800 1651 Gi0/0.147 192.168.142.44 Null 192.168.110.47 01 0000 0000 166 Т.е. с 192.168.110.47 и 192.168.200.7 адрес 192.168.142.44 не пингуется, что видно по DstIf==Null, НО в то же время с 192.168.110.5 и 192.168.200.7 (из тех же подсетей, что и пострадавшие хосты) замечательно пингуется. Сам маршрутизатор по адресу 192.168.142.41 тоже отовсюду пингуется. Никаких ACL запрещающих нигде нет (в т.ч. на 192.168.142.44), роутер пингует все стороны (с любых src ip). Стал отлаживать, но из интересного нашел только такие сообщени в debug ip cef drops на каждый ICMP reply: Feb 4 08:52:30 192.168.110.1 : CEF-Drop: Packet from 192.168.142.44 (Gi0/0.147) to 192.168.200.7, Link-layer broadcast/multicast Feb 4 08:52:31 192.168.110.1 : CEF-Drop: Packet from 192.168.142.44 (Gi0/0.147) to 192.168.110.47, Link-layer broadcast/multicast Т.е. IOS считает 192.168.110.47 и 192.168.200.7 броадкастовыми/мультикастовыми адресами (хотя там 192.168.110.0/24 и 192.168.200.7/32) и выкидывает пакеты. Что можно покрутить чтобы нормализовать роутинг? А то только-только подобрал IOS, где MPPE реально работает, а тут такая засада. P.S.: в логах только %IP_VFR-7-FEATURE_DISABLE_IN: VFR(in) is manually disabled through CLI; VFR support for features that have internally enabled, will be made available only when VFR is enabled manually on interface Virtual-Access39 при поднятии туннелей, неясно как это выключить. show-ip-cef-drop.txt