Hello everyone,

Sniffing the trafic withsnifferon my CCR1009-8G-1S-1S+ I can see some weird IPs :

• 129.0.0.10
• 129.0.0.20
• 129.0.0.30
• 129.0.0.40

Why Weird ? Because of the end numbers (too perfects to be real IPs) and because of the fact that the device (CCR1009-8G-1S-1S+) is behind a strict gateway which does not allows incoming trafic from these.
This trafic only appears if thefilter-interfaceis empty. Snffing the trafic on every single interface (ether1,ether2,sfp1) does not show any 129.0.0.x.
分析了在Wireshark突出捕获文件bad layer2 frames :

Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)

Do you have an idea ?
Regards.

up ?

Why don't you post the entire captured frame?

Why don't you post the entire captured frame?

Privacy issueNot my decision unfortunately.

Now that we have more traffic on the router, the problem seems obviously related to bad UDP frames :



This is SIP traffic generated by SBC appliances (Session Border Controler).
I will check this.

Apparently broken equipment that sends garbage ethernet frames (with non-random garbage).
Not something related to your router, I think.

Of course this shows how useful it is to sometimes do a capture and look what is going on.

I'm seeing this too. And it's hard to figure out where the traffic is coming from because the routeros sniffer either doesn't work right or it's lying to me because it shows the traffic on bond1 when interface is any:

1 0.035 bond1 129.0.0.71:49320 172.28.0.15:1891 tcp 188 1 noBut if I sniff on bond1 it doesn't show up.

Also this doesn't match anything either:
/ip firewall mangle
add action=log chain=postrouting log-prefix=TEST src-address=129.0.0.0/16
add action=log chain=prerouting log-prefix=TEST src-address=129.0.0.0/16
add action=log chain=input log-prefix=TEST src-address=129.0.0.0/16
add action=log chain=output log-prefix=TEST src-address=129.0.0.0/16
add action=log chain=forward log-prefix=TEST src-address=129.0.0.0/16
add action=log chain=postrouting dst-address=129.0.0.0/16 log-prefix=TEST
add action=log chain=prerouting dst-address=129.0.0.0/16 log-prefix=TEST
添加action = =输入dst-address = 129.0.0.0/1日志链6 log-prefix=TEST
add action=log chain=output dst-address=129.0.0.0/16 log-prefix=TEST
add action=log chain=forward dst-address=129.0.0.0/16 log-prefix=TEST

Something isn't right....

same here - running on x86

ether1 has no ip address assigned, having vlan interfaces attached to it - maybe this is the issue?

Those are valid IP's... My honeypots have seen traffic them from many times.

NetRange: 129.0.0.0 - 129.0.255.255
CIDR: 129.0.0.0/16
NetName: AFRINIC-ERX-129-0-0-0
NetHandle: NET-129-0-0-0-1
Parent: NET129 (NET-129-0-0-0-0)
NetType: Transferred to AfriNIC
Organization: African Network Information Center (AFRINIC)
裁判:https://whois.arin.net/rest/net/NET-129-0-0-0-1
OrgId: AFRINIC
Address: Level 11ABC
Address: Raffles Tower
Address: Lot 19, Cybercity
City: Ebene
Country: MU

Valid IP address range would not explain why those packets do not get picked up by any firewall filter nor can I see those packets within wireshark.

I suspect that someone has two concurrent connections to Internet: one with your LAN and the second with eg. LTE and parts of LTE traffic is "leaking" to LAN interface.

The bytes counters are incredible - 4GB - and I run the sniffer only for approx 5 seconds each time (I am using PtP to connect to VLAN, around 40Mbit/s)

When I change VLANID, Src Addresses 129.0.x.x changes in captured connections, as long as existing connect exist prior to switching to none existing vlanXXX -- ?

What is 10.10.219.2 device ?

it is the local IP address assigned to vlan219.


# /snip
# sep/24/2016 11:32:46 by RouterOS 6.37
#
/interface bridge
add mtu=1500 name=BridgeLOCAL
add name=bridgeVLAN219

/interface vlan
add arp=enabled interface=ether2 mac-address=00:0C:42:D3:D3:97 name=vlan219 \
vlan-id=219

/interface bridge port
add bridge=BridgeLOCAL interface=ether3
add bridge=BridgeLOCAL interface=ether4
add bridge=bridgeVLAN219 interface=vlan219

/ip address
add address=172.17.3.1/24 interface=BridgeLOCAL network=172.17.3.0
add address=10.10.219.2/24 interface=bridgeVLAN219 network=10.10.219.0


/ip firewall nat
add action=masquerade chain=srcnat dst-address=10.0.0.0/8 out-interface=\
bridgeVLAN219

/ip route
add distance=1 dst-address=10.0.0.0/8 gateway=10.10.219.1

Anyone @ Mikrotik?

Hi,

I was debugging my configuration with the tool "Packet Sniffer" from 2 routers "RB2011UiAS-2HnD-IN" with the OS 6.37.1 and I found myself seeing similar traffic. In my case the source IP is always 129.0.0.3. The weired part:
- The direction is always TX.
- I can't see the traffic on the destination addresses (sniffing with tcpdump on the destination host).
- I can't see it entering the routers.
- In one router the traffic is always TCP on the other is always UDP.
- It happens on interfaces that are used as TRUNKs but the packet is on the parent interface and not in any of the VLANs.

I included the raw data of one of the packages. I see similar raw data on a valid traffic between a PC and a IP camera.
I hope this help to solve this problem.

I'm getting the 129 addresses in captures too. It looks like the packets are being damaged or the record of the packet is damaged. I have 172.16.*.* devices talking, and wireshark will show the source address as 129.0.0.*.

This happens on the CCR ROS 6.36.3, but not on a 450G with the same version.

Hello,

I'm exactly in the same case.
I've weird 129.0.0.vlanid packet broadcasting inside the vlan. Sometimes when users need more network ressources, the flow can gros as the consumed bandwith. Sometimes i had above 10Mbits/s or 20Mbits of weird traffic.
It doesn't get caught by firewall and not visible in wireshark.
It's not internet flow cause we disabled internet interface while rebooting router and switch.

If someone have new info or tips,....


regards.

To illustrate these packet & conection:

To detail a bit more :

- On the top of network I've 2 DSL link with mangle in LB mode (ECMP) on a RB2011
- 1 trunk port with 5 VLans in RB 2011 going to a CRS with access ports & trunk port corresponding to these vlans.

All 129.0.0.X IP talk to clients in all vlan and network device on the same port.
I believe it's some broadcast by mikrotik device in routing or hidden things.
When traffic up a bit more, "broadcast" is done in access ports with equal TX bandwith.

Same problem on CCR-1036 RouterOS 6.37.rc13!!!!
Someone have found problem?!?!??!
Traffic cant catch on firewall!! Dont show in Tourch!!!
Most packets are damaged!
I found that the IP is from Cameroon and some connection with Online Money MTM...
i was thinking- discovered the problem - mobile phone in my wifi network, but strange - reset phone to default...Sniffer still show traffic src 129.0.0.1, 45, 145.... etc. SO it was not some virus or something!!
Please... Mikrotik!! IT is big problem! Why firewall FORWARD dont catch it??!??!

I have now noticed it myself during debugging of a VLAN issue. It appears to happen only on an interface
where VLAN traffic is present, and it shows only on the built-in sniffer not on the actual network.

So I guess it is a bug in the sniffer. That explains as well why it cannot be caught using firewall filters.

As you said, the traffic can't be catched by firewall forward / input / output rules.
It doesn't show in torch.

I tried to disable pppoe client for wan, rebooting the router, the connection still exist (from 129.X IP to IP of gateway or clients in network).

I have also a pptp server for VPN, then in a vpn session this 129.X ip contact le vpn client in the other side.

当我们看到这些IPs,我们尝试to wireshark the network, but theses connections doesn't appear.

Sometimes i can see these packet to a real public IP, could it be a sort of multicast thing ?

I hope this is a sniffer bug ..

Maybe a mikrotik man could read this...

I think it is a bug in the packet sniffer which forgets to increment its analysis pointer past the VLAN
header when it is analysing a VLAN packet. The ethertype of 802.3Q is hex 8100 and the VLAN number
(with some other bits at the top) follow after that. So when a packet for VLAN 4 is received it will
have 81 00 00 04 at the front, and when that is interpreted as an IP header it would get decoded
as 129.0.0.4

My RB2011 is connected to a CRS226 with access vlan & trunk ports.
As in the RB there are a lot of 129.X IP, i can see a lot of broadcast in the CRS on all connected ports.
I can't see in each interfaces what happening in, and also for the 129.X IP on the CRS.
What i see on the interface list is all connected ports have same TX traffic, mort traffic in the switch, more broadcast comme on all connected ports.
Sometimes it "cut" the network (as I've VOIP, the communication cut).

it's the same if i disconnect all device, i can see the broadcast on connected ports (trunk to the RB).

I see the same problem with 6.37.4. It seems to be a problem on interfaces which have tagged vlans. As I see the same problem on multiple routers which are not on the same subnet it can't be a damaged NIC or wrong configured client. We've also activated reverse path filtering so its not possible that traffic would be able to traffic over an router to the next. I believe that the last past of the IP address is actually the vlan ID.

e.g. ether1 has a vlan with ID 188 on it and I see packets with 129.0.0.188:2620 on the ether1 interface.

I've reported that problem in ticket 2017020822000589, and Sergejs has acknowledged a bug with handling tagged packets and they will fix it.

Good to hear! Having the same issue on my RB1100AHx2.

Same bug RB1100AHx2 + RB2011iL

No need to confirm same bug with yet another screenshot. It is known already.

Noticed this as well on an RB1100AHx2 running 6.38.1, was wondering what on earth it was.

Updated to latest 6.39.2, re-ran the packet capture and this time didn't see it, so hopefully fixed during one of the those updates.

Ah looks like it was this latest one from June 6th, I couldn't see it at first in all the change logs, skimmed over them, then searched for 129.0 and packet capture

sniffer - fixed VLAN tags when sniffing all interfaces;

Great job Mikrotikthank you.