Hi

There is a network, drew
Mikrotik with the IP address 192.168.2.33/24 from the office does not ping, but it goes through Mac-telnet, all other devices are pinged. Also, if you go to Mikrotik 192.168.2.33/24 from it, the ping goes to 192.168.2.34, 192.168.2.31, 192.168.2.51 but does not ping 192.168.2.1, I'm sure in the settings
Such MT a few what can I do ? These MT they have subscribers in different VLAN is working without problems

You might want to explain which exact Mikrotik products you are using, and how they are configured.

You might want to explain which exact Mikrotik products you are using, and how they are configured.

model = 921UAGS-5SHPacT with antennas mANT 19S

Have I understood it correctly that ping cannot get through the QinQ cloud but mac-telnet can, and that this is only a problem for VLAN 202 while other VLANs on the same path work OK?

Or is this problem related only to the OFFICE device, i.e. when you log in (using mac-telnet) to the 10.2.90.33, you can ping 10.2.90.1 from there but cannot ping 10.2.90.200?

Your description is hard to understand as you use English words with your native language's grammar. Can you reveal your native language, please?

Have I understood it correctly that ping cannot get through the QinQ cloud but mac-telnet can, and that this is only a problem for VLAN 202 while other VLANs on the same path work OK?

Yes, the ping does not pass through the qinq cloud, and only 202 VLANs, all other VLANs work without problems.
202 VLANs are management VLANs, the rest are for cpe

Не могли бы вы раскрыть свой родной язык, пожалуйста?

My native language is Russian, my English is bad I'm sorry

И проблема только с MT, другие устройства работают пинг проходит

My native language is Russian

Я приблизительно так и подумал, и благодаря этому я смог дешифровать информацию. "из офиса не пинуется" следует перевести как "does not respond to pings coming from the office", чтоб было однозначно.

Yes, the ping does not pass through the qinq cloud, and only 202 VLANs, all other VLANs work without problems.
202 VLANs are management VLANs, the rest are for cpe
И проблема только с MT, другие устройства работают пинг проходит

I'd set hw=no on all the /interface bridge port rows and then use /tool sniffer quick ip-protocol=icmp to find out what's going on. You should see whether the frame carrying the packet arrives properly tagged to the ingress port, passes through the CPU-facing port of the bridge still tagged, and then can be seen untagged on the /interface vlan. The response packet should take the reverse path.

The Mikrot logs contain these messages

ether1: bridge port received packet with own address as source address (6c:3b:6b:a7:e0:86), probably loop

Although there is no loop

Check that the bridge MAC addresses are unique, different for each device.

Check that the bridge MAC addresses are unique, different for each device.

Yes, the Mac addresses in the network are unique, I tried to reset and re-configure, it did not help

Have you tried the sniffing as I've suggested in my previous post?

The network consists of too many elements so you have to narrow the search to one of them, and sniffing will help you in that.

I made /tool sniffer uploaded the file

https://my-files.su/z3r1vb

That's great, but what I had in mind was that you'd be sniffing on the interfaces of all the devices on the path between the one which sends the ping requests and the one which should respond them, and find out at which device you can see the missing packets last.

You have posted a pcap from some point in your network but you haven't identified that point. I would suppose it is the Mikrotik with the address .33 from which you have posted the configuration (as the pcap is full of MAC Telnet packets and you've mentioned that MAC-Telnet works), but I can see ping requests sent by a Mikrotik with address .32 - one to .31, which is responded, and another one to .2, which is not responded.

So I adjust my assumption, concluding that you've taken the sniff at the Mikrotik with address .32, demonstrating that ping from it to .31 works and ping from it to .2 doesn't.

But you haven't written whether you were pinging also from .2 to .32 while sniffing, nor have you shown a sniffer result from the .2 itself.

So it is hard to advise anything if you don't give sufficient and clearly described input data.

What is interesting is that the ARP requests from .2 are seen in the pcap, so the L2 path between .2 and .32 is not completely broken.