[myst]

Коллеги, всю головную кость сломал.

Надо прокинуть пачку влан между 

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 утра? =))

Спасибо.

[RN3DCX]

bebug ospf - запускали?

 

OSPF соседство как правило не происходит по причине разного MTU на конечных точках.

[myst]

В 11.11.2021 в 05:43, RN3DCX сказал:

bebug ospf - запускали?

 

OSPF соседство как правило не происходит по причине разного MTU на конечных точках.

да выше вывод дебага. про мту там есть но я не понимаю двух вещей где я ошибся и почему не поднимается соседство бгп 

 

[RN3DCX]

В 10.11.2021 в 22:48, myst сказал:

да выше вывод дебага

мало инфы, предположу, что не всё включили в вывод.

 

Гугл говорит:

Цитата

Описываемые вами симптомы могут быть результатом проблем с MTU в промежуточной сети. Можете ли вы включить «debug ip ospf adj», и это может дать некоторые подсказки о причине проблемы.

 

Кстати, а перед тем как пускать через оператора на столе/стенде проверяли?

[myst]

В 11.11.2021 в 06:24, RN3DCX сказал:

мало инфы, предположу, что не всё включили в вывод.

 

Гугл говорит:

 

Кстати, а перед тем как пускать через оператора на столе/стенде проверяли?

в вывод я включил какраз deb ip ospf aj.. что же касательно проблемы на сети провайдера то врятли, куинку работает, иначе бы интерфейсы в 999 влане друг друга никак не пинговали... я подробно рассписал в транке провом прокинут влан 910

[myst]

В 11.11.2021 в 06:24, RN3DCX сказал:

мало инфы, предположу, что не всё включили в вывод.

проблема в том что инфа исчерпывающая, в первом посте я описал вообще все что хоть как-то может касаться данной темы.

[SUrov_IBM]

В 10.11.2021 в 21:08, myst сказал:

telnet/ssh в 999 влане бегает.

Myst, здравствуйте.

Извините, возможно задам глупый вопрос, ICMP запрос с MTU 1500 и запретом фрагментации проходит нормально (ping x.x.x.x df-bit size 1500)?

[stalker86]

1500 с DF  он и не пройдёт. С Учётом ICMP заголовка должно.
1472 bytes (MTU minus 20 bytes IP header and 8 bytes for the ICMP header).

[myst]

В 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 

[SUrov_IBM]

В 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).

[myst]

В 11.11.2021 в 08:59, SUrov_IBM сказал:

ip ospf network point-to-point

естественно пробовал, я по старой привычке всегда этот тип сети по умолчанию использую... вобщем, никакой разницы с бродкастом.

[SUrov_IBM]

Просто как предположение, если попробовать принудительно снизить MTU в VLAN 999 до 1400 и добавить ip ospf mtu-ignore (хотя оно и было у Вас на 1500) на обеих сторонах? Это, только для эксперимента, если не повредит конфигурации.

[myst]

В 11.11.2021 в 09:32, SUrov_IBM сказал:

Просто как предположение, если попробовать принудительно снизить MTU в VLAN 999 до 1400 и добавить ip ospf mtu-ignore (хотя оно и было у Вас на 1500) на обеих сторонах? Это, только для эксперимента, если не повредит конфигурации.

да не, напоминаю что так же не работает бгп. зато работает ссш.

[SUrov_IBM]

В 11.11.2021 в 02:33, myst сказал:

да не, напоминаю что так же не работает бгп.

Странно, что iBGP не работает. Но, возможно у не работоспособности OSPF и BGP разные корни проблемы. Насколько MTU влияет на BGP боюсь судить, теоретически ему из-за может MTU поплохеть, он ведь TCP использует, но у Вас и 1500 летает. Скорей всего SNR кривляется, как Вы и предполагаете. Для очистки совести и ради эксперимента, я бы попробовал MTU до 1400 ужать. ;)

[StSphinx]

На BGP очень даже влияет TCP MSS. Когда пиры не договорились, именно такая ситуация и будет - висеть в Active. Накушался, когда настраивал BGP между железками Cisco и Juniper.

А TCP MSS Cisco пытается считать исходя из Path MTU Discovery, который включен по умолчанию, на некотором железе.

[Garra-67]

Мультикаст на транзитной сети не фильтруется?

Я так долго искал подвох, почему ospf не работает, ведь пингуется всё.

 

[snvoronkov]

1 час назад, Garra-67 сказал:

Мультикаст на транзитной сети не фильтруется?

Я так долго искал подвох, почему ospf не работает, ведь пингуется всё.

 

+1

 

Попробуйте уникастом завязаться.

[YuryD]

5w1d: OSPF: First DBD and we are not SLAVE

[YuryD]

В 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 в другом месте вполне обрабатывал, сначала квагга, затем железка. Что я делал не так ?

 

[StSphinx]

В 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 так же будет получаться разный.

[YuryD]

В 15.11.2021 в 18:21, StSphinx сказал:

Это скорее я не так делал. Железки смотрели друг на друга интерфейсами с разным MTU. Juniper и Cisco считают MTU по разному. Cisco считает то, что влезает в Ethernet фрейм, а Juniper считает к этому еще и размер заголовка. Соответственно, без всяких QinQ и VLAN, MTU будет 1500 и 1514 соответственно.

1. коммутаторы не должны изучать размеры ип-пакетов и фрагментировать-склеивать их снова, это дело маршрутизаторов.

2. коммутатор не должен изучать что там в пакете, кроме заголовка с мак-адресом.

3. коммутатор должен отбросить любой пакет, превышающий размер мту на его порту, или без срс, или не влезаший в его буфера на порту, согласно политике store+forward.  Пакет от клиента должен быть принять весь целый, поставлен в соотв  очередь с битами  tos, и изученный направлен в очередь в исходящий порт далее.

 

И да, не теребите МТУ у себя, возможно верхнему провайдеру придется менять оборудование, было у нас.

[YuryD]

суть то qinq проста - пропихните пакеты потолще без модификаций по дороге, а уж мы-то тут навертим в пакет свои, а вы сверху свое и передайте, а уж мы сами разпакуем. Т.е. надо просто чтобы пакеты тольще стандартного езернета 1540 проходили. мту на магистрали и у монстров толще, но и глюков у них больше.

[smelnik]

Привет. Судя по всему у тебя маршрутизаторы не могут определить кто первый шлёт DBD-пакет и является мастером на линке.

Но я бы как минимум посмотрел бы наличие ошибок по трассе и снял бы дамп.

[myst]

Проблема решилась. Перенес соседство OSPF на 3750, все взлетело как надо.