Broadcast packets from vlan clients - odd results

Hey Guys,

I have my clients on vlans, APs on management vlan. My router behind my AP is getting odd Mikrotik Discovery Protocol messages coming in from the Mikrotik clients located behind my Mimosa C5x CPEs.

It almost seems like maybe an issue of MTU. As if the packet is getting stripped of some info when the vlan tag is added. Any thoughts, suggestions?

tried enabling jumbo mtu - does not seem to help!

system mtu jumbo 2474 in ios. show int giX/X verifies MTU is at 2474

Are you terminating the VLANs on that router? I mean, if the router is on the VLANs then it’s going to see discovery broadcasts from other routers on the same VLAN…

What is odd about the Discovery Protocol messages?

Yes they should be seeing the broadcasts, the issue is that the IP address field is coming through “jumbled up” so say if it was it will show up as or something very similar. Not causing any major issues as this seems to only be these broadcast messages, but obviously something is not right!

I could pull pcap’s from originating device and receiving device to compare?

That’s probably your best option. If the packet was getting screwed up by the link, you would be seeing a lot of malformed, CRC or FCS errors on the link.

Source or Destination IP address? For a broadcast address, assuming a /24 network and using your IP example, it would be for the Destination IP. If it’s a DHCP Discover or Request, then the Source IP will be and the Destination IP will be For a DHCP Offer or ACK message, the Source IP will be that of the DHCP server and the Destination IP will be If you have a DHCP Relay (Helper) in the mix, that will change the messages. The above assumes the computer and DHCP server are on the same VLAN.

These start as layer 2 broadcast messages going to FF:FF:FF:FF:FF:FF which eventually gets translated to if that helps!

I have some other links using Mikrotik PtMP and the data is coming through fine. Just on my Mimosa PtMP clients.

No errors on ports, all other info is coming through OK. Just the data holding the IP Address being broadcasted in these packets. Not to be confused with the source IP - this is the IP Address data field located in the data payload of the packet, not the source IP of the packet itself.

These start as layer 2 broadcast messages going to FF:FF:FF:FF:FF:FF which eventually gets translated to<<

That’s what I would expect to see for a broadcast message.

Was there a problem to begin with that caused you to look or did you just happen to find these when you used Wireshark? If there wasn’t a problem, then I would suspect that there’s something on that link sending the messages you mention. If you find out what that is, it may answer your question about the messages themselves. If there was a problem showing up, then knowing what the problem was may help with the diagnosis.

We know the source, it is a Mikrotik routerboard. We are expecting to see these packets. The issue is that the packets contain invalid data - the data is valid leaving the device and invalid when received so the perceived issue is somewhere between the C5X and A5C.

MT1 = Mikrotik Router 1 (where broadcast packet is originating)
MT2 = Mikrotik Router 2 (where broadcast packet is received)

MT1 <-ethernet-> C5X <-wireless-> A5C <-ethernet-> Cisco Switch <-ethernet-> MT2

Show CDP Neighbors detail on Cisco Switch shows:
Device ID: [John Doe]
Entry address(es):
IP address: - [this is showing correct here, modified for obv reasons]
Platform: MikroTik, Capabilities: Router
Interface: GigabitEthernet0/24, Port ID (outgoing port): ether1
Holdtime : 117 sec

Version :
6.47.9 (long-term)

advertisement version: 1
Power Available TLV:

Power request id: 0, Power management id: 0, Power available: 0, Power management level: 0

Management address(es):

But on MT2 it is showing up malformed. Not sure if CDP uses the source IP vs Mikrotik Discover Protocol using IP from data in packet. Will do some more homework and post any results I find!

If I’m understanding you correctly, the packet from MT1 is OK at the Cisco switch, but bad by the time it reaches MT2. For starters, CDP will only work on adjacent devices. So, the MT1 CDP packet shouldn’t be getting to MT2. It should stop at the Cisco Switch. So, I don’t know what’s getting to MT2, but it should NOT be CDP from MT1. If it is, it makes me wonder if there’s a problem with the Mikrotik implementation of CDP. Have you tried LLDP instead? That is usually more multi-vendor compatible.

So digging here it looks like MNDP just spans layer 2 broadcast domains. Mikrotik’s also blast out discovery messages on CDP, LLDP, and MNDP.

So I may be seeing CDP messages in one spot and MNDP in another. I will trim this out by protocol and see if that can shed some more light here!