myst Опубликовано 10 ноября, 2021 · Жалоба Коллеги, всю головную кость сломал. Надо прокинуть пачку влан между SNR-S2995G и 6509 поверх провайдерской сети. На интерфейсах в сторону провайдера mtu 1514. Провайдером прокинут влан 910. На обоих свичах сделана физическая петля между двумя портами. interface GigabitEthernet3/1 description # QinQ Loop # switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 10,777,888,999 switchport mode trunk no cdp enable spanning-tree bpdufilter enable spanning-tree bpduguard enable ! interface GigabitEthernet3/2 description # QinQ Tunnel # switchport switchport access vlan 910 switchport mode dot1q-tunnel no cdp enable spanning-tree bpdufilter enable spanning-tree bpduguard enable с обоих сторон поднят влан интерфейс interface Vlan999 description # L3 OSP to SPK # ip address 192.168.99.1 255.255.255.252 ip ospf network point-to-point пинги есть, телнет в обе стороны тоже проходит. А дальше начинается самое интересное. Не могу поднять ни ospf ни bgp соседство. router ospf 100 router-id 172.16.255.255 log-adjacency-changes redistribute connected subnets route-map OSPF-SPK-OUT redistribute static subnets route-map OSPF-SPK-OUT passive-interface default no passive-interface Vlan999 network 192.168.99.0 0.0.0.3 area 1 висит в стостоянии EXSTART хоть ты тресни. (всякие mtu-ignore пробовал) в debug ip ospf 5w1d: OSPF: Send DBD to 172.16.255.254 on Vlan999 seq 0xF1A opt 0x52 flag 0x7 len 32 5w1d: OSPF: Retransmitting DBD to 172.16.255.254 on Vlan999 [10] 5w1d: OSPF: Rcv DBD from 172.16.255.254 on Vlan999 seq 0x1E8D opt 0x42 flag 0x7 len 32 mtu 1500 state EXSTART 5w1d: OSPF: First DBD and we are not SLAVE и все собственно. С iBGP точно такая же история Висит в состоянии Active и финиш. Te6/4 # Провайдер 10G # 1514 остальные интерфейсы 1500 interface TenGigabitEthernet6/4 description # Провайдер 10G # switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 734,910 switchport mode trunk mtu 1514 no cdp enabl Повторюсь, telnet/ssh в 999 влане бегает. Где я втупляю в 4 утра? =)) Спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RN3DCX Опубликовано 10 ноября, 2021 · Жалоба bebug ospf - запускали? OSPF соседство как правило не происходит по причине разного MTU на конечных точках. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 10 ноября, 2021 · Жалоба В 11.11.2021 в 05:43, RN3DCX сказал: bebug ospf - запускали? OSPF соседство как правило не происходит по причине разного MTU на конечных точках. да выше вывод дебага. про мту там есть но я не понимаю двух вещей где я ошибся и почему не поднимается соседство бгп Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RN3DCX Опубликовано 10 ноября, 2021 · Жалоба В 10.11.2021 в 22:48, myst сказал: да выше вывод дебага мало инфы, предположу, что не всё включили в вывод. Гугл говорит: Цитата Описываемые вами симптомы могут быть результатом проблем с MTU в промежуточной сети. Можете ли вы включить «debug ip ospf adj», и это может дать некоторые подсказки о причине проблемы. Кстати, а перед тем как пускать через оператора на столе/стенде проверяли? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 10 ноября, 2021 · Жалоба В 11.11.2021 в 06:24, RN3DCX сказал: мало инфы, предположу, что не всё включили в вывод. Гугл говорит: Кстати, а перед тем как пускать через оператора на столе/стенде проверяли? в вывод я включил какраз deb ip ospf aj.. что же касательно проблемы на сети провайдера то врятли, куинку работает, иначе бы интерфейсы в 999 влане друг друга никак не пинговали... я подробно рассписал в транке провом прокинут влан 910 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 10 ноября, 2021 · Жалоба В 11.11.2021 в 06:24, RN3DCX сказал: мало инфы, предположу, что не всё включили в вывод. проблема в том что инфа исчерпывающая, в первом посте я описал вообще все что хоть как-то может касаться данной темы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SUrov_IBM Опубликовано 10 ноября, 2021 · Жалоба В 10.11.2021 в 21:08, myst сказал: telnet/ssh в 999 влане бегает. Myst, здравствуйте. Извините, возможно задам глупый вопрос, ICMP запрос с MTU 1500 и запретом фрагментации проходит нормально (ping x.x.x.x df-bit size 1500)? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stalker86 Опубликовано 10 ноября, 2021 · Жалоба 1500 с DF он и не пройдёт. С Учётом ICMP заголовка должно. 1472 bytes (MTU minus 20 bytes IP header and 8 bytes for the ICMP header). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 10 ноября, 2021 · Жалоба В 11.11.2021 в 07:02, SUrov_IBM сказал: Myst, здравствуйте. Извините, возможно задам глупый вопрос, ICMP запрос с MTU 1500 и запретом фрагментации проходит нормально (ping x.x.x.x df-bit size 1500)? конечно проверял вообще я грешу на снр.. там по соседству 3750я есть, попробую на ней все это поднять 6506_core_rou#ping 192.168.99.2 size 1500 df-bit Type escape sequence to abort. Sending 5, 1500-byte ICMP Echos to 192.168.99.2, timeout is 2 seconds: Packet sent with the DF bit set !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms это ОЧЕНЬ странная и не очевидная проблема. 5w1d: OSPF: Retransmitting DBD to 172.16.255.254 on Vlan999 [11] 5w1d: OSPF: Rcv DBD from 172.16.255.254 on Vlan999 seq 0x21EB opt 0x42 flag 0x7 len 32 mtu 1500 state EXSTART 5w1d: OSPF: First DBD and we are not SLAVE 5w1d: OSPF: Send DBD to 172.16.255.254 on Vlan999 seq 0x18ED opt 0x52 flag 0x7 len 32 5w1d: OSPF: Retransmitting DBD to 172.16.255.254 on Vlan999 [12] 5w1d: OSPF: Rcv DBD from 172.16.255.254 on Vlan999 seq 0x21EB opt 0x42 flag 0x7 len 32 mtu 1500 state EXSTART 5w1d: OSPF: First DBD and we are not SLAVE 5w1d: OSPF: Send DBD to 172.16.255.254 on Vlan999 seq 0x18ED opt 0x52 flag 0x7 len 32 5w1d: OSPF: Retransmitting DBD to 172.16.255.254 on Vlan999 [13] 5w1d: OSPF: Rcv DBD from 172.16.255.254 on Vlan999 seq 0x21EB opt 0x42 flag 0x7 len 32 mtu 1500 state EXSTART 5w1d: OSPF: First DBD and we are not SLAVE 5w1d: OSPF: Send DBD to 172.16.255.254 on Vlan999 seq 0x18ED opt 0x52 flag 0x7 len 32 5w1d: OSPF: Retransmitting DBD to 172.16.255.254 on Vlan999 [14] 5w1d: OSPF: Rcv DBD from 172.16.255.254 on Vlan999 seq 0x21EB opt 0x42 flag 0x7 len 32 mtu 1500 state EXSTART 5w1d: OSPF: First DBD and we are not SLAVE 5w1d: OSPF: Send DBD to 172.16.255.254 on Vlan999 seq 0x18ED opt 0x52 flag 0x7 len 32 вот дебаг оспф эдженси... больше нет совершенно ничего. но как мы видем 1500 пролетают с DF Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SUrov_IBM Опубликовано 10 ноября, 2021 · Жалоба В 11.11.2021 в 00:25, myst сказал: грешу на снр.. Возможно, SNR очень своеобразно воспринимает интерфейс Vlan999 при QinQ схеме. К сожалению, с оборудованием SNR не знаком, можно попробовать использовать ip ospf network point-to-point для Vlan999 (если SNR поддерживает), чтобы изменить режим работы OSPF? В 11.11.2021 в 00:17, stalker86 сказал: 1500 с DF он и не пройдёт. С Учётом ICMP заголовка должно. Stalker86, здравствуйте. Для тестирования под ОС WINDOWS, это справедливо. Для утилиты ping в IOS, указывается то значение, которое вы проверяете (с флагом df-bit). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 10 ноября, 2021 · Жалоба В 11.11.2021 в 08:59, SUrov_IBM сказал: ip ospf network point-to-point естественно пробовал, я по старой привычке всегда этот тип сети по умолчанию использую... вобщем, никакой разницы с бродкастом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SUrov_IBM Опубликовано 10 ноября, 2021 · Жалоба Просто как предположение, если попробовать принудительно снизить MTU в VLAN 999 до 1400 и добавить ip ospf mtu-ignore (хотя оно и было у Вас на 1500) на обеих сторонах? Это, только для эксперимента, если не повредит конфигурации. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 10 ноября, 2021 · Жалоба В 11.11.2021 в 09:32, SUrov_IBM сказал: Просто как предположение, если попробовать принудительно снизить MTU в VLAN 999 до 1400 и добавить ip ospf mtu-ignore (хотя оно и было у Вас на 1500) на обеих сторонах? Это, только для эксперимента, если не повредит конфигурации. да не, напоминаю что так же не работает бгп. зато работает ссш. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SUrov_IBM Опубликовано 10 ноября, 2021 · Жалоба В 11.11.2021 в 02:33, myst сказал: да не, напоминаю что так же не работает бгп. Странно, что iBGP не работает. Но, возможно у не работоспособности OSPF и BGP разные корни проблемы. Насколько MTU влияет на BGP боюсь судить, теоретически ему из-за может MTU поплохеть, он ведь TCP использует, но у Вас и 1500 летает. Скорей всего SNR кривляется, как Вы и предполагаете. Для очистки совести и ради эксперимента, я бы попробовал MTU до 1400 ужать. ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
StSphinx Опубликовано 11 ноября, 2021 · Жалоба На BGP очень даже влияет TCP MSS. Когда пиры не договорились, именно такая ситуация и будет - висеть в Active. Накушался, когда настраивал BGP между железками Cisco и Juniper. А TCP MSS Cisco пытается считать исходя из Path MTU Discovery, который включен по умолчанию, на некотором железе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Garra-67 Опубликовано 14 ноября, 2021 · Жалоба Мультикаст на транзитной сети не фильтруется? Я так долго искал подвох, почему ospf не работает, ведь пингуется всё. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snvoronkov Опубликовано 14 ноября, 2021 · Жалоба 1 час назад, Garra-67 сказал: Мультикаст на транзитной сети не фильтруется? Я так долго искал подвох, почему ospf не работает, ведь пингуется всё. +1 Попробуйте уникастом завязаться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 15 ноября, 2021 · Жалоба 5w1d: OSPF: First DBD and we are not SLAVE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 15 ноября, 2021 · Жалоба В 15.11.2021 в 17:36, YuryD сказал: 5w1d: OSPF: First DBD and we are not SLAVE Наш новый редактор сообщений не дал мне способ добавить ответ. Переведите и посмотрите, что у Вас в конфигах про ospf и авторизацию. Было бы i/e bgp подсказал бы... В логах обеих сторон. Далее дебажить, с обеих сторон, отчего нет согласия. Ну и да, tcp и udp немного разные.... В 11.11.2021 в 13:30, StSphinx сказал: На BGP очень даже влияет TCP MSS. Когда пиры не договорились, именно такая ситуация и будет - висеть в Active. Накушался, когда настраивал BGP между железками Cisco и Juniper. А TCP MSS Cisco пытается считать исходя из Path MTU Discovery, который включен по умолчанию, на некотором железе. Это как ? Имею в управлении обычную ibgp меж сиско7206, и софтами с кваггой и под пингвином и под freebsd, экий треугольник, трое долбятся за натом. Ну и ebgp мою AS в другом месте вполне обрабатывал, сначала квагга, затем железка. Что я делал не так ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
StSphinx Опубликовано 15 ноября, 2021 · Жалоба В 15.11.2021 в 16:01, YuryD сказал: Наш новый редактор сообщений не дал мне способ добавить ответ. Переведите и посмотрите, что у Вас в конфигах про ospf и авторизацию. Было бы i/e bgp подсказал бы... В логах обеих сторон. Далее дебажить, с обеих сторон, отчего нет согласия. Ну и да, tcp и udp немного разные.... Это как ? Имею в управлении обычную ibgp меж сиско7206, и софтами с кваггой и под пингвином и под freebsd, экий треугольник, трое долбятся за натом. Ну и ebgp мою AS в другом месте вполне обрабатывал, сначала квагга, затем железка. Что я делал не так ? Это скорее я не так делал. Железки смотрели друг на друга интерфейсами с разным MTU. Juniper и Cisco считают MTU по разному. Cisco считает то, что влезает в Ethernet фрейм, а Juniper считает к этому еще и размер заголовка. Соответственно, без всяких QinQ и VLAN, MTU будет 1500 и 1514 соответственно. И соответственно TCP MSS так же будет получаться разный. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 15 ноября, 2021 · Жалоба В 15.11.2021 в 18:21, StSphinx сказал: Это скорее я не так делал. Железки смотрели друг на друга интерфейсами с разным MTU. Juniper и Cisco считают MTU по разному. Cisco считает то, что влезает в Ethernet фрейм, а Juniper считает к этому еще и размер заголовка. Соответственно, без всяких QinQ и VLAN, MTU будет 1500 и 1514 соответственно. 1. коммутаторы не должны изучать размеры ип-пакетов и фрагментировать-склеивать их снова, это дело маршрутизаторов. 2. коммутатор не должен изучать что там в пакете, кроме заголовка с мак-адресом. 3. коммутатор должен отбросить любой пакет, превышающий размер мту на его порту, или без срс, или не влезаший в его буфера на порту, согласно политике store+forward. Пакет от клиента должен быть принять весь целый, поставлен в соотв очередь с битами tos, и изученный направлен в очередь в исходящий порт далее. И да, не теребите МТУ у себя, возможно верхнему провайдеру придется менять оборудование, было у нас. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 15 ноября, 2021 · Жалоба суть то qinq проста - пропихните пакеты потолще без модификаций по дороге, а уж мы-то тут навертим в пакет свои, а вы сверху свое и передайте, а уж мы сами разпакуем. Т.е. надо просто чтобы пакеты тольще стандартного езернета 1540 проходили. мту на магистрали и у монстров толще, но и глюков у них больше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
smelnik Опубликовано 16 ноября, 2021 · Жалоба Привет. Судя по всему у тебя маршрутизаторы не могут определить кто первый шлёт DBD-пакет и является мастером на линке. Но я бы как минимум посмотрел бы наличие ошибок по трассе и снял бы дамп. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 24 ноября, 2021 · Жалоба Проблема решилась. Перенес соседство OSPF на 3750, все взлетело как надо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...