EoIP - tunnel drops after 60 secs

RouterOS General
1

Hi all,

I have setup my first EoIP tunnel and having issues. The tunnel worked for about 60 secs after that my user reports that the tunnel is no longer working; i do not have control of what is attached to the tunnel.
One end client is still learning the MAC address of the other end client, but the other is not.

I have used loopback addresses for the two remote ip addresses of the tunnel and I have connectivty between the loopback interfaces.

Here is the relevant configuration.

[user@rtr-lon-02] > interface export

jul/01/2019 08:54:09 by RouterOS 6.39.1

software id = TKF9-KLBU

/interface bridge
add name=ML-LAN
add admin-mac=6C:3B:6B:60:28:5A auto-mac=no name=bridgeLocal
add name=loopback0
add name=loopback1
/interface ethernet
set [ find default-name=ether1 ] comment=gi1/0/5-sw-lon-01
set [ find default-name=ether2 ] comment=gi1/0/6-sw-lon-01
set [ find default-name=ether3 ] comment=gi1/0/8-sw-lon-03
set [ find default-name=ether4 ] disabled=yes
set [ find default-name=ether8 ] comment=gi1/0/7-sw-lon-01
/interface eoip
add mac-address=FE:E0:EA:35:6E:84 name=ml-eoip remote-address=172.31.254.14 tunnel-id=1
/interface gre
/interface vlan
add comment=BKP-UK-IP-HUB01 interface=ether1 name=BKP-P2P-HUB01 vlan-id=141
add interface=ether1 name=MPLS vlan-id=1000
add interface=ether1 name=NAT-TEST vlan-id=108
add comment=UK-IP interface=ether1 name=P2P-HUB01 vlan-id=111
add comment=UK-IP-02 interface=ether1 name=P2P-HUB02 vlan-id=113
add interface=ether8 name=P2P-LON01 vlan-id=2
add interface=ether8 name=P2P-SAGA vlan-id=11
add interface=ether1 name=SAGA_VRF_GBL vlan-id=85
add interface=ether1 name=SW-MGMT vlan-id=254
add interface=ether2 name=TIBUS1 vlan-id=503
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=ML-LAN interface=ml-eoip
add bridge=ML-LAN interface=ether3
/interface l2tp-server server
set caller-id-type=ip-address

/ip address
add address=172.18.0.15/24 interface=MPLS network=172.18.0.0
add address=172.31.254.15 interface=loopback0 network=172.31.254.15
add address=192.168.192.6/30 interface=Tunnel105 network=192.168.192.4
add address=192.168.103.25/30 interface=Tunnel22 network=192.168.103.24
add address=192.168.108.1/25 interface=NAT-TEST network=192.168.108.0
add address=192.168.111.1/24 interface=SW-MGMT network=192.168.111.0
add address=172.31.253.138/30 interface=P2P-HUB01 network=172.31.253.136
add address=192.168.192.14/30 interface=Tunnel115 network=192.168.192.12
add address=172.31.253.166/30 interface=P2P-HUB02 network=172.31.253.164
add address=172.31.253.190/30 interface=P2P-LON01 network=172.31.253.188
add address=172.31.253.206/30 interface=BKP-P2P-HUB01 network=172.31.253.204
add address=10.101.40.93/26 interface=P2P-SAGA network=10.101.40.64
add address=192.168.76.10/27 interface=SAGA_VRF_GBL network=192.168.76.0

add address=192.168.76.10/27 interface=SAGA_VRF_GBL network=192.168.76.0
[fulvio.allegretti@rtr-lon-02] > ping 172.31.254.14
SEQ HOST SIZE TTL TIME STATUS
0 172.31.254.14 56 61 33ms
1 172.31.254.14 56 61 32ms
2 172.31.254.14 56 61 32ms
3 172.31.254.14 56 61 32ms
4 172.31.254.14 56 61 32ms
5 172.31.254.14 56 61 32ms
6 172.31.254.14 56 61 32ms
sent=7 received=7 packet-loss=0% min-rtt=32ms avg-rtt=32ms max-rtt=33ms

[user@rtr-mkt-a5] > interface export

serial number = 742906A43B4E

/interface bridge
add name=ML-LAN
add name=lo0
/interface ethernet
set [ find default-name=ether1 ] comment=sw-cpd-a4-1/0/41 speed=100Mbps
set [ find default-name=ether2 ] comment=sw-cpd-a5-1/0/22 speed=100Mbps
set [ find default-name=ether3 ] comment=PMI-IDIRCORE-MDSW-1-port46 speed=100Mbps
set [ find default-name=ether4 ] disabled=yes speed=100Mbps
set [ find default-name=ether5 ] disabled=yes speed=100Mbps
set [ find default-name=ether6 ] disabled=yes speed=100Mbps
set [ find default-name=ether7 ] disabled=yes speed=100Mbps
set [ find default-name=ether8 ] disabled=yes speed=100Mbps
set [ find default-name=sfp-sfpplus1 ] advertise=10M-full,100M-full,1000M-full disabled=yes
set [ find default-name=sfp-sfpplus2 ] advertise=10M-full,100M-full,1000M-full disabled=yes
/interface eoip
add mac-address=FE:C4:65:77:C3:DE name=ml-eoip remote-address=172.31.254.15 tunnel-id=1
/interface vlan
add interface=ether1 name=p2p-hub-01 vlan-id=25
add interface=ether2 name=p2p-hub-02 vlan-id=26
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=""
/interface bridge port
add bridge=ML-LAN interface=ml-eoip
add bridge=ML-LAN interface=ether3

/ip address
add address=172.16.254.32/24 interface=ether7 network=172.16.254.0
add address=172.31.254.14 interface=lo0 network=172.31.254.14
add address=172.31.253.225/30 interface=p2p-hub-01 network=172.31.253.224
add address=172.31.253.229/30 interface=p2p-hub-02 network=172.31.253.228

[omniaccess@rtr-mkt-a5] > ping 172.31.254.15
SEQ HOST SIZE TTL TIME STATUS
0 172.31.254.15 56 62 33ms
1 172.31.254.15 56 62 32ms
2 172.31.254.15 56 62 32ms
3 172.31.254.15 56 62 32ms
4 172.31.254.15 56 62 32ms
5 172.31.254.15 56 62 32ms
6 172.31.254.15 56 62 32ms
7 172.31.254.15 56 62 32ms
8 172.31.254.15 56 62 32ms

What am I doing wrong?

Thanks

EoIP doesn't work on RB493
2

Type really fast… :wink:

3

What you write sounds to me as if the tunnel never actually goes up in one direction, and those 60 seconds are simply the time until the receiving end notices that. This might be caused by some firewall misconfiguration or some unintended NAT handling.

So instead of the “relevant” configuration, post the complete configuration (using hide-sensitive and other anonymisation, see my automatic signature). Also, after the 60 seconds expire, what is the output of /interface eoip print and of /ip firewall connection print detail where protocol~“gre” at both Mikrotiks?

4

thank you both (you too anav, always appreciate a funny comment)
@sindy - I have hidden the sensitive information and sent the complete config of one router, rtr-mk-a5, the other one will take a little longer.

In the meantime here is a little more info and some screenshots of info on the winbox, hope it helps.

“one end” of the tunnel is working fine, my client can see the MAC addresses of the other end and the arp is complete:
this switch below is attached to ether3 of the rtr-lon-02 and I have created an interfce in vlan3504 ip 172.16.123.1/30

sw-lon-03#sh ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 172.16.123.1 - 7069.5a98.fac9 ARPA Vlan3504
Internet 172.16.123.2 0 28d2.44f6.67f0 ARPA Vlan3504

172.16.123.2 is a laptop at the other end of the tunnel, attached to rtr-mk-a5

The mikrotik where 172.16.123.2 is attached to it is seeing the MAC address 7069.5a98.fac9 (see screenshot .14) but it does not pass it to the client.

One other intersting fact I have noticed, the MAC address of the client 172.16.123.1, 7069.5a98.fac9, is only learnt by rtr-mk-a5 when I ping the broadcast address 172.16.123.3 (it is a /30 subnet), if I ping 172.16.123.2 is not learnt.
In actual fact when I ping 172.16.123.2 rtr-lon-02 does not see that mac address on ether3, it is only when I ping .3 that the mac address appears on rtr-lon-02 ether3 and then on rtr-mkt-a5

I have attached two screen shots, the first one shose the bridge hosts when I ping 172.16.123.2 from sw-lon-03. The second one when I ping 172.16.123.3.

My guess is that I have an issue on rtr-lon-02

Here is also the output of the print command you asked:

[omniaccess@rtr-mkt-a5] > interface eoip print
Flags: X - disabled, R - running
0 R name=“ml-eoip” mtu=1400 actual-mtu=1400 l2mtu=65535 mac-address=FE:C4:65:77:C3:DE arp=enabled arp-timeout=auto loop-protect=default loop-protect-status=off loop-protect-send-interval=5s
loop-protect-disable-time=5m local-address=0.0.0.0 remote-address=172.18.0.15 tunnel-id=1 keepalive=10s,10 dscp=inherit clamp-tcp-mss=yes dont-fragment=no allow-fast-path=yes
[omniaccess@rtr-mkt-a5] > ip firewall connection print detail where protocol gre-protocol
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat

[fulvio.allegretti@rtr-lon-02] > interface eoip print
Flags: X - disabled, R - running
0 R name=“ml-eoip” mtu=1400 actual-mtu=1400 l2mtu=65535 mac-address=FE:E0:EA:35:6E:84 arp=enabled arp-timeout=auto loop-protect=default loop-protect-status=off loop-protect-send-interval=5s
loop-protect-disable-time=5m local-address=0.0.0.0 remote-address=172.31.253.229 tunnel-id=1 keepalive=10s,10 dscp=inherit clamp-tcp-mss=yes dont-fragment=no allow-fast-path=yes
[fulvio.allegretti@rtr-lon-02] > ip firewall connection print detail where protocol gre-protocol
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat
rtr-mk-a5.txt (4.05 KB)
screen shot 2.JPG
screen shot 1.JPG

5

From phone, thus brief: do the connection print exactly as I’ve written it, protocol~“gre”. It is important.

6

Thanks sindy.
need to find out what this command actually do:
very different output, at London I have:

[user@rtr-lon-02] > ip firewall connection print detail where protocol~“gre”
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat
0 ESAC d protocol=gre src-address=y.202.182.109 dst-address=X.1Z.140.18 reply-src-address=a.b.226.206 reply-dst-address=y.202.182.109 gre-key=40025 timeout=4h59m59s
orig-packets=1 X1 095 orig-bytes=331 332 573 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=2 347 010 repl-bytes=219 972 118 repl-fasttrack-packets=0
repl-fasttrack-bytes=0 orig-rate=1936bps repl-rate=2.2kbps

1 C protocol=gre src-address=172.31.253.229 dst-address=172.18.0.15 reply-src-address=172.18.0.15 reply-dst-address=172.31.253.229 gre-key=256 timeout=29s orig-packets=3 011
orig-bytes=283 331 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=0 repl-bytes=0 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=648bps repl-rate=0bps

2 SAC protocol=gre src-address=X.1Z.140.1 dst-address=69.y.3.117 reply-src-address=69.y.3.117 reply-dst-address=X.1Z.140.1 gre-key=0 timeout=2m59s orig-packets=3 605 249 y1
orig-bytes=3 482 325 060 629 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=57 968 816 repl-bytes=4 920 471 351 repl-fasttrack-packets=0 repl-fasttrack-bytes=0
orig-rate=3.9Mbps repl-rate=354.4kbps

3 SAC protocol=gre src-address=X.1Z.140.1 dst-address=69.y.3.116 reply-src-address=69.y.3.116 reply-dst-address=X.1Z.140.1 gre-key=0 timeout=2m59s orig-packets=16 648 030
orig-bytes=2 950 Z3 013 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=2 140 repl-bytes=321 720 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps
repl-rate=2.2kbps

4 SAC protocol=gre src-address=X.1Z.140.1 dst-address=209.159.173.2 reply-src-address=209.159.173.2 reply-dst-address=X.1Z.140.1 gre-key=0 timeout=2m55s orig-packets=609 445 265
orig-bytes=522 059 350 305 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=11 434 651 repl-bytes=977 668 351 repl-fasttrack-packets=0 repl-fasttrack-bytes=0
orig-rate=0bps repl-rate=0bps

5 ESAC d protocol=gre src-address=199.167.137.247 dst-address=X.1Z.140.62 reply-src-address=a.b.227.226 reply-dst-address=199.167.137.247 gre-key=56355 timeout=4h59m59s
orig-packets=606 529 orig-bytes=84 394 316 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=790 256 repl-bytes=66 486 421 repl-fasttrack-packets=0
repl-fasttrack-bytes=0 orig-rate=808bps repl-rate=592bps

6 C protocol=gre src-address=172.18.0.15 dst-address=172.31.253.229 reply-src-address=172.31.253.229 reply-dst-address=172.18.0.15 gre-key=256 timeout=29s orig-packets=67 683
orig-bytes=9 X2 766 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=0 repl-bytes=0 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=832bps repl-rate=0bps

7 ESAC d protocol=gre src-address=Z.10.56.244 dst-address=X.1Z.140.62 reply-src-address=a.b.227.226 reply-dst-address=Z.10.56.244 gre-key=49490 timeout=4h59m44s orig-packets=152 433
orig-bytes=9 127 829 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=190 811 repl-bytes=10 159 833 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps


Interesting line 1 and 6. don’t know exactly what the output means yet but it is peculiar to see on line 1 the src-address to be the ip address of my other router, rtr-mkt-a5.

on rtr-mkt-a5 I see:
[user@rtr-mkt-a5] > ip firewall connection print detail where protocol~“gre”
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat
[user@rtr-mkt-a5] >

basically nothing. my first reaction is that this is like one big bridge without including what’s attached to ether3 of rtr-mkt-a5 (just intuition, need to read a little more about it).

Also attached the rtr-lon-02 config, hopefully without too much sensitive info.

Thanks again for your help, really appreciated
rtr-lon-02_no_sensitive.txt (37.4 KB)

7

When reading your post on the mobile, I’ve only checked the output of the /ip firewall connection print and I wrote that brief post to fix that.

Now at the PC, this is what seems most important to me from your post #4:

The MAC address is learnt from any incoming frame. So if the 172.16.123.1 was sending arp requests for 172.16.123.2 to the cable connected to ether3, you would see 70:69:5a:98:fa:c9 in the output of /interface bridge host print; if you don’t, you can be pretty sure the Cisco switch in between or the actual device on which 172.16.123.1/30 is up do not forward the frame carrying the ARP packet to you.

It is not clear from the export what Mikrotik model is rtr-lon-02, so better do /interface bridge port set [find interface~“ether3”] hw=no, and then run /tool sniffer quick interface=ether3 and try to ping 172.16.123.2 from 172.16.123.1 again (after, say, 15 minutes from the last attempt to let the MAC expire in all the ARP and FDB tables). You should see whether the frames come in or not. If they don’t, the issue is unrelated not only to EoIP but even to rtr-lon-02. If you can only see one ARP request and one ARP response and nothing more, it is likely the case.

Also, do you have to take some special measures at the 172.16.123.1 machine when pinging 172.16.123.3? Normally it is not possible to ping an address from a system which treats it as a broadcast one unless you provide an option to ping telling it that it is really your intention. So if you don’t need to do that, it is possible that the netmask at 172.16.123.1 is not set properly. This should, however, not be related to your issue, it is just strange.

Last point is the /ip firewall connection print. I don’t get what is wrong with the Mikrotik firewall but this is not the only case where the GRE connection between two IP addresses is not treated as a single one but as two unidirectional connections (1 and 6 in your case). As gents have fixed a netfilter bug in 6.45.1, maybe this issue has been resolved as a side effect, I haven’t checked yet. But what is much worse is that there is no connection shown at the rtr-mkt-a5. As the EoIP packets are originated locally, there is no way how the GRE packets carrying the EoIP payload could escape the firewall, so the only explanation which comes to my mind is that you have some rules in /ip firewall filter raw with action=notrack.

8

Thanks again sindy.

On the point "The MAC address is learnt from any incoming frame....." I agree with you. There is no device in the middle. In order to test, I disconnected the real clients at both ends. I created a vlan interface on the switch wich is directly attached to the rtr-lon-02 ether3. At the other end I put a laptop to ether3. Checked the ip address assignment, 172.16.123.0/30. To be honest i saw incosistent behaviour, the MAC address was sometime learnt when the london client was arping for .2

I have decided to upgrade the software before carrying on with troubleshooting.

What I am finding really frustrating is the fact that the MAC addresses of the remote clients are seen on the remote router.

For example, mac address 0035.1a06.9858, is of a client at the London end:

[user@rtr-lon-02] > interface bridge host print
Flags: L - local, E - external-fdb
BRIDGE MAC-ADDRESS ON-INTERFACE AGE
ML-LAN 00:35:1A:06:98:58 ether3 1s
L ML-LAN 6C:3B:6B:60:28:5C ether3 0s
ML-LAN 70:69:5A:98:FA:88 ether3 24s
ML-LAN FE:C4:65:77:C3:DE ml-eoip 0s
L ML-LAN FE:E0:EA:35:6E:84 ml-eoip 0s

we can see it on ether3, the interface facing the clients at london, and at the other end

[omniaccess@rtr-mkt-a5] > interface bridge host print
Flags: X - disabled, I - invalid, D - dynamic, L - local, E - external

MAC-ADDRESS VID ON-INTERFACE BRIDGE AGE

0 DL 0E:FA:BD:15:43:69 lo0 lo0
1 D 00:07:7D:BB:11:80 ether3 ML-LAN 4s
2 D 00:35:1A:06:98:58 ml-eoip ML-LAN 1s
3 D 00:3A:7D:50:FF:D5 ether3 ML-LAN 1s
4 DL 6C:3B:6B:60:23:34 ether3 ML-LAN
5 D 70:69:5A:98:FA:88 ml-eoip ML-LAN 2s
6 DL FE:C4:65:77:C3:DE ML-LAN ML-LAN
7 D FE:E0:EA:35:6E:84 ml-eoip ML-LAN 33s

we see it on the tunnel interface ml-eoip as we should but the client on ether3 does not get it, its arp is incomplete.

In the opposite directions, the macs of the clients attached to rtr-mkt-a5, are seen by the clients attached to rtr-lon-02, the arp for 172.16.253.2 completed at lon-02 client.

On the firewall point:
[omniaccess@rtr-mkt-a5] > ip firewall raw print
Flags: X - disabled, I - invalid, D - dynamic
[omniaccess@rtr-mkt-a5] >

Not sure what else to check.

Will update you after the upgrade to the rtr-lon-02 (do you know if the radius problem is solved on 6.45.1?)

Thanks
Fulvio

9

Post the full (anonymized) configuration export of rtr-mkt-a5. Too many mysteries exist there simultaneously.

10

Hi sindy, that was posted already (not much to hide there, I am using this router just for tunnel). It is with the post of the screenshots. I am attaching it here again.
rtr-mk-a5.txt (3.95 KB)

11

OK, it was camouflaged in the grey area around the pictures :slight_smile:

So one mystery gone, something is telling me that when no firewall rules are defined at all, the connection tracking is disabled as nothing needs it so it would be a waste of CPU to track connections, so there is really nothing to be shown by /ip firewall connection print. Which means there can be no NAT-related complications etc.

What remains is the mystery of the ARP table population on the host connected to ether3 of rtr-mk-a5. Can you make the cli window as wide as your screen allows at both rtr-lon-02 and rtr-mk-a5 and run /tool sniffer quick interface=ether3,ml-eoip at both machines simultaneously while trying to ping first from the host connected to rtr-lon-02 and then again in the opposite direction, and post the results here? After two pings in each direction, regardless the result, show also the result of /interface bridge host print where interface~“ether3|ml-eoip”. I still maintain that the issue has nothing to do with EoIP as if I got you right, you can see the MAC of each host connected locally to ether3 in the bridge host table on the remote Mikrotik as accessible through the EoIP. I can also see no bridge filter or bridge nat rules, nor any non-default settings of the bridge behaviour.

12

Hi Sindy,

Attached is the information you’ve requested, I am also attacheing a jpeg showing the setup.

Looking at the output there what seems to be apparent is that for some reasons the client attached to ether3 of rtr-mkt-a5 does not get the mac of 172.16.123.1 and keeps arping for it even though that MAC 70:69:5A:98:FA:C9 is clearly available on rtr-mkt-a5.

This is the same thing my “customer” was complaining about, he could see the mac addresses at the rtr-lon-02 end but not at rtr-mkt-a5 end.

As said before, I have now disconnected the customer’s devices and put a laptop at one end anda vlan interface at the remote end.

Many thanks again for your help.
topology.JPG
EoIP troubleshoot.txt (3.52 KB)

13

You’ve posted a wrong file - the printout of the connection tracking has already been in one of the posts above. I am interested in the seeing arp request/arp reply exchange as seen from both ends, especially whether the arp responses did make it out to the connected laptop at rtr-mkt-a5 via ether3.

14

apologies, that was before my third coffee. correct file attached
troubleshooting EoIP info.txt (21.8 KB)

15

To me it looks like an issue between ether3 interface of rtr-mkt-05 (inclusive, as the sniffing on ether3 takes place on the driver and there is still place for a bug between the sniffing point and the wire) and the connected laptop. The data below clearly show that the arp response from 70:69:5A:98:FA:C9/172.16.123.1 is received via ml-eoip and forwarded out via ether3, but the laptop acts as if it has never received the response.
ether3 8.16 10 ← 28:D2:44:F6:67:F0 FF:FF:FF:FF:FF:FF 172.16.123.2: who has 172.16.123.1? arp 60 35 no
ml-eoip 8.16 9 → 28:D2:44:F6:67:F0 FF:FF:FF:FF:FF:FF 172.16.123.2: who has 172.16.123.1? arp 60 35 no
ml-eoip 8.194 11 ← 70:69:5A:98:FA:C9 28:D2:44:F6:67:F0 172.16.123.1: at 70:69:5A:98:FA:C9 arp 60 27 no
ether3 8.194 12 → 70:69:5A:98:FA:C9 28:D2:44:F6:67:F0 172.16.123.1: at 70:69:5A:98:FA:C9 arp 60 27 no
…
ether3 8.782 15 ← 28:D2:44:F6:67:F0 FF:FF:FF:FF:FF:FF 172.16.123.2: who has 172.16.123.1? arp 60 35 no
ml-eoip 8.782 14 → 28:D2:44:F6:67:F0 FF:FF:FF:FF:FF:FF 172.16.123.2: who has 172.16.123.1? arp 60 35 no
ml-eoip 8.817 16 ← 70:69:5A:98:FA:C9 28:D2:44:F6:67:F0 172.16.123.1: at 70:69:5A:98:FA:C9 arp 60 27 no
ether3 8.817 17 → 70:69:5A:98:FA:C9 28:D2:44:F6:67:F0 172.16.123.1: at 70:69:5A:98:FA:C9 arp 60 27 no
Is the same laptop used at rtr-mkt-05 side as while 172.16.123.1 was the real gear in London? Can you run Wireshark or tcpdump on that laptop and see whether it receives the ARP responses? It may be some firewall, anti-virus or VPN software running on that laptop which causes the trouble.

Also, can you try to shut down the EoIP tunnel, attach 172.16.123.1/30 directly to the bridge interface ML-LAN and see how the 172.16.123.2 behaves when you ping it from the rtr-mkt-05 (ping in one window, sniff in another)?

16

quick reply before running the suggested test.

The laptop has been connected to troubleshoot, in the real solution a switch is attaced to rtr-mkt-a5 eth3. the switch is managed by a “customer” and was reporting the same behaviour, could not see any mac address on the interface attached to ether3, this kind of exlude FW/antivurs issues (also the laptop is able to ping when attached to a differen network).

Will run the test and post outcome

17

this is my interpretation of what you asked me to do

Disable eoip interface on rtr-mkt-a5
[omniaccess@rtr-mkt-a5] /ip address> /interface eoip print
Flags: X - disabled, R - running
0 X name="ml-eoip" mtu=1400 actual-mtu=1400 l2mtu=65535 mac-address=FE:C4:65:77:C3:DE arp=enabled arp-timeout=auto loop-protect=default loop-protect-status=off loop-protect-send-interval=5s
loop-protect-disable-time=5m local-address=0.0.0.0 remote-address=172.18.0.15 tunnel-id=1 keepalive=10s,10 dscp=inherit clamp-tcp-mss=yes dont-fragment=no allow-fast-path=yes

\

assign ip address 172.16.123.1/30 to bridge interface

serial number = 742906A43B4E

/ip address
add address=172.31.254.14 interface=lo0 network=172.31.254.14
add address=172.31.253.229/30 interface=p2p-hub-02 network=172.31.253.228
add address=172.16.123.1/30 # serial number = 742906A43B4E


I get the same results, the laptop keeps arping for it. attached are the two capture.

The first one ping to client when the eoip was still enabled
the second one "ping to router" when ip address assigned to interface=ML-LAN

If I understand the significance of this test, the laptop should be able to pint ML-LAN, afterall thes interfaces are in the same bridge.

Do I conclude I have an issue with my rtr-mkt-a5 router? I have another MikroTik, is it worth trying a different router?

pingtorouter.JPG
pingtorouter.JPG1549×775 256 KB

pingtoclient.JPG
pingtoclient.JPG1512×742 259 KB

18

I would first try just another etherX instead of ether3 on the rtr-mkt-a5 (you have a lot of unused ones there), but otherwise yes, as you get the same result with completely unrelated devices (laptop and switch) connected to the ether3, the issue must be at the side which remains unchanged, which is the Mikrotik one. Theoretically it may also be a RouterOS or firmware issue (these two are separate things, after upgrading RouterOS it is recommended to upgrade also the firmware as a separate step, the firmware comes packed with the RouterOS but is not automatically applied), so before trashing the current hardware of rtr-mkt-a5, check this first. I.e. I would first do /system routerboard upgrade followed by /system reboot or use another etherX instead of ether3, depending on whether you can reboot the router any time and whether /system routerboard print shows a difference between current-firmware and upgrade-firmware value. When/if the current-firmware version matches the RouterOS version (6.43.4) and use of another etherX yields the same (bad) result, the next step is a complete software upgrade to some current version (at least the long-term 6.43.16 as of now). Hardware replacement would be the very last step for me.

19

Gi Sindy,
moving the cable to ether4 made it work. What’s with that? For you to suggest it, you must have seen this before. Any possible logical explanation?
Thanks very much for your help.

20

In my native language we say “I’ve seen a snake crawling back and a horse vomiting” (for us IT guys, neither is possible).

So yes, I’ve seen before cases where L1 is up and sniff shows outgoing traffic locally but the remote end receives nothing. There is still some software and hardware between the sniffing point and the wire; if software was so broken, it would be unlikely that it would happen only on a single port. So a broken hardware was much more likely.