Page 1 of 1

Problems with MT

Posted: Thu Oct 29, 2020 7:24 am
by Suhrab
Image

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

Re: Problems with MT

Posted: Thu Oct 29, 2020 7:07 pm
by aesmith
You might want to explain which exact Mikrotik products you are using, and how they are configured.

Re: Problems with MT

Posted: Fri Oct 30, 2020 5:32 am
by Suhrab
You might want to explain which exact Mikrotik products you are using, and how they are configured.
model = 921UAGS-5SHPacT with antennas mANT 19S
/interface bridge
add name=bridge1
/interface wireless
set [ find default-name=wlan1 ] antenna-gain=1 band=5ghz-a/n/ac disabled=no \
    frequency=5765 frequency-mode=superchannel mode=ap-bridge \
    nv2-preshared-key=xxxx  nv2-security=enabled radio-name=xxx\
    rx-chains=0,1,2 ssid=xxx tx-chains=0,1,2 wds-default-bridge=bridge1 \
    wds-mode=dynamic wireless-protocol=nv2
/interface ethernet
set [ find default-name=ether1 ] advertise=\
    10M-half,10M-full,100M-half,100M-full
set [ find default-name=sfp1 ] disabled=yes
/interface wireless nstreme
set wlan1 disable-csma=yes enable-nstreme=yes
/interface vlan
add interface=bridge1 name=vlan202 vlan-id=202
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge filter
add action=drop chain=forward mac-protocol=vlan out-bridge=bridge1
/interface bridge port
add bridge=bridge1 interface=wlan1
add bridge=bridge1 interface=ether1
add bridge=bridge1 disabled=yes interface=sfp1
/ip address
add address=10.2.90.33/24 interface=vlan202 network=10.2.90.0
/ip route
add distance=1 gateway=10.2.90.1

Re: Problems with MT

Posted: Fri Oct 30, 2020 9:18 am
by sindy
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?

Re: Problems with MT

Posted: Fri Oct 30, 2020 11:49 am
by Suhrab
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, другие устройства работают пинг проходит

Re: Problems with MT

Posted: Fri Oct 30, 2020 12:46 pm
by sindy
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.

Re: Problems with MT

Posted: Thu Nov 19, 2020 5:17 am
by Suhrab
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

Re: Problems with MT  [SOLVED]

Posted: Thu Nov 19, 2020 10:46 am
by aesmith
Check that the bridge MAC addresses are unique, different for each device.

Re: Problems with MT

Posted: Thu Nov 19, 2020 11:22 am
by Suhrab
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

Re: Problems with MT

Posted: Thu Nov 19, 2020 7:54 pm
by sindy
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.

Re: Problems with MT

Posted: Sat Nov 21, 2020 12:37 pm
by Suhrab
I made /tool sniffer uploaded the file

https://my-files.su/z3r1vb

Re: Problems with MT

Posted: Sat Nov 21, 2020 9:24 pm
by sindy
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.