Community discussions

MikroTik App
 
shilov
just joined
Topic Author
Posts: 5
Joined: Wed Jul 07, 2021 10:42 pm

Ethernet Broadcast packets on CRS125

Wed Jul 07, 2021 10:55 pm

Model: CRS125-24G-1S-2HnD
RouterOS: 6.47.10 (latest LTS for now)
Brief problem description: no Ethernet Broadcast packets forwarded to or from 802.1Q port

I have simple interconnection scheme:
Server - 2U - SW1 - 2T - SW2 - 2U - Client
Server is connected to SW1 port in access mode (VLAN2 Untagged).
SW1 is SF200 series Cisco switch.
SW1 and SW2 (port ether1) interconnected as 802.1Q Trunks.
Client is connected to ether2 port in access mode (VLAN2 Untagged).
About SW2 I have two versions of the test:
1. SW2 is RB750 device. There is no issue. Everything works fine.
2. SW2 is changed to CRS125-24G-1S-2HnD interconnected the same way. ether1 - to SW1, ether2 - to Client. Client can't get IP-address by DHCP.
I started Wireshark on Server with capture filter based on Client's MAC Address.
I can see for example IPv4 and IPv6 packets coming to Server with theese MAC Addresses as Destination:
- 01:00:5e:7f:ff:fa (SSDP Multicast)
- 01:00:5e:00:00:fc (LLMNR Multicast)
- 33:33:00:01:00:02 (DHCPv6 Multicast)
- 33:33:00:01:00:03 (LLMNR Multicast)
- 33:33:00:00:00:02 (ICMPv6 Multicast)
But not even one Ethernet Broadcast.
Also I have remote management on CRS125 in VLAN9 with no problem.
I did Packet Capture on SW2 port ether2 and I can see UDP packets to 0.0.0.0:bootps (ethernet broadcast) coming from Client.
And I didn't see this kind of packets on ether1.

Changing SW2 back to RB750 resolves an issue.

Can you please help me to resolve problem with CRS125?

CRS125 meanful configuration:
/interface bridge
add admin-mac=CC:2D:E0:99:7E:EB auto-mac=no comment=defconf name=bridge
add name=bridge-wireless
add name=bridge1
/interface vlan
add interface=bridge1 name=vlan-mgmt vlan-id=9
add interface=ether1 name=vlan-wireless vlan-id=6
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
add address-pool=default-dhcp disabled=no interface=bridge name=defconf
/interface bridge port
add bridge=bridge1 comment=defconf interface=ether2
add bridge=bridge1 comment=defconf interface=ether3
add bridge=bridge1 comment=defconf interface=ether4
add bridge=bridge1 comment=defconf interface=ether5
add bridge=bridge1 comment=defconf interface=ether6
add bridge=bridge1 comment=defconf interface=ether7
add bridge=bridge1 comment=defconf interface=ether8
add bridge=bridge1 comment=defconf interface=ether9
add bridge=bridge1 comment=defconf interface=ether10
add bridge=bridge1 comment=defconf interface=ether11
add bridge=bridge1 comment=defconf interface=ether12
add bridge=bridge1 comment=defconf interface=ether13
add bridge=bridge1 comment=defconf interface=ether14
add bridge=bridge comment=defconf interface=ether15
add bridge=bridge comment=defconf interface=ether16
add bridge=bridge comment=defconf interface=ether17
add bridge=bridge comment=defconf interface=ether18
add bridge=bridge comment=defconf interface=ether19
add bridge=bridge comment=defconf interface=ether20
add bridge=bridge comment=defconf interface=ether21
add bridge=bridge comment=defconf interface=ether22
add bridge=bridge comment=defconf interface=ether23
add bridge=bridge comment=defconf interface=ether24
add bridge=bridge comment=defconf interface=sfp1
add bridge=bridge-wireless comment=defconf interface=wlan1
add bridge=bridge1 interface=ether1 trusted=yes
add bridge=bridge disabled=yes interface=vlan-data
add bridge=bridge-wireless interface=vlan-wireless
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface ethernet switch egress-vlan-tag
add tagged-ports=ether1 vlan-id=2
add tagged-ports=ether1,switch1-cpu vlan-id=9
add tagged-ports=ether1 vlan-id=3
/interface ethernet switch ingress-vlan-translation
add customer-vid=0 new-customer-vid=2 ports="ether2,ether3,ether4,ether5,ether6,\
    ether7,ether8,ether9,ether10,ether11,ether12,ether14"
add customer-vid=0 new-customer-vid=3 ports=ether13
/interface ethernet switch vlan
add comment=DATA ports="ether1,ether2,ether3,ether4,ether5,ether6,ether7,ether8,\
    ether9,ether10,ether11,ether12,ether14" vlan-id=2
add comment=MGMT ports=ether1,switch1-cpu vlan-id=9
add comment=PRN ports=ether1,ether13 vlan-id=3
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf disabled=yes interface=ether1 list=WAN
add interface=vlan-mgmt list=LAN
add interface=bridge1 list=LAN
/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge network=\
    192.168.88.0
add address=10.0.0.2/28 interface=vlan-mgmt network=10.0.0.0
/ip dhcp-client
add comment=defconf interface=ether1
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=\
    invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" \
    connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=\
    out,none out-interface-list=WAN
/ip route
add distance=1 gateway=10.0.0.1
/system package update
set channel=long-term
 
tdw
Forum Guru
Forum Guru
Posts: 1843
Joined: Sat May 05, 2018 11:55 am

Re: Ethernet Broadcast packets on CRS125

Thu Jul 08, 2021 8:27 pm

The bridge setup is a mess - you have no connectivity between bridge containing ether2-24 plus sfp1, and bridge1 containing ether1. Remove the extra bridges, move the other interfaces from them to bridge, configure wlan1 VLAN membership.
 
shilov
just joined
Topic Author
Posts: 5
Joined: Wed Jul 07, 2021 10:42 pm

Re: Ethernet Broadcast packets on CRS125

Thu Jul 08, 2021 10:35 pm

The bridge setup is a mess - you have no connectivity between bridge containing ether2-24 plus sfp1, and bridge1 containing ether1. Remove the extra bridges, move the other interfaces from them to bridge, configure wlan1 VLAN membership.
Thank you for your answer!
'bridge' is just default configuration.
If you look closer to config, you'll see that both ether1 and ether2 (we are talking about in this issue) are parts of bridge1.
Other interfaces are also exists in configuration, but it looks like it makes a bit confusing...
 
tangent
Forum Guru
Forum Guru
Posts: 1351
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Ethernet Broadcast packets on CRS125

Thu Jul 08, 2021 11:48 pm

I agree with tdw: you really need to get rid of that second bridge and all the 192.168.88.0/24 stuff. Help us help you.

The thing that caught my eye is the "drop all from WAN not DSTNATed" rule. Are you trying to make these broadcast packets traverse the WAN interface? Is that what the "2T" obscurity is in your ASCII network diagram? If so, the broadcast packets might not be masqueraded, so they'll hit this rule.

The IP firewall in MT products has ways of monitoring based on the rules hit. You should be able to trace a packet through the chain to find out where it dies. If you can't even see it enter the chain, that's also interesting. Let us know what you find out.
 
shilov
just joined
Topic Author
Posts: 5
Joined: Wed Jul 07, 2021 10:42 pm

Re: Ethernet Broadcast packets on CRS125

Fri Jul 09, 2021 12:08 am

I agree with tdw: you really need to get rid of that second bridge and all the 192.168.88.0/24 stuff. Help us help you.

The thing that caught my eye is the "drop all from WAN not DSTNATed" rule. Are you trying to make these broadcast packets traverse the WAN interface? Is that what the "2T" obscurity is in your ASCII network diagram? If so, the broadcast packets might not be masqueraded, so they'll hit this rule.

The IP firewall in MT products has ways of monitoring based on the rules hit. You should be able to trace a packet through the chain to find out where it dies. If you can't even see it enter the chain, that's also interesting. Let us know what you find out.
Thank you, again, for your attention.
But..."drop all from WAN" works only for incoming packets? If I'm not wrong... And I'm talking about packets received on Server's site.
So it's about outgoing firewall - I have no deny on my chain rules for that kind of packets.
And once again... I have no problem with receiving of multicast traffic on remote side.
 
shilov
just joined
Topic Author
Posts: 5
Joined: Wed Jul 07, 2021 10:42 pm

Re: Ethernet Broadcast packets on CRS125

Fri Jul 09, 2021 12:34 am

Once again... submitting what I have.
I have no problem with receiving multicast ethernet traffic from Client on Server.
I have no some kind of deny rules for outgoing traffic.
So this kind of traffic must reach Server side.
 
tangent
Forum Guru
Forum Guru
Posts: 1351
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Ethernet Broadcast packets on CRS125

Fri Jul 09, 2021 2:19 am

"drop all from WAN" works only for incoming packets?

No, look at the rule: chain=forward, in-interface-list=WAN

What we don't know — because you haven't told us! — is whether the WAN is involved at all. If these two routers are on opposite sides of the WAN link, then yes, packets being forwarded through the router from the WAN will be subject to this rule.

What is "2T"?

I'm talking about packets received on Server's site.

Okay, so are the packets transiting the WAN link at all, or are they getting stopped before they get there?

If you don't know, don't guess. Use the router's Torch or Packet Sniffer tool on the inbound and outbound interfaces separately to find out for certain.

I have no deny on my chain rules for that kind of packets.

The rule I'm citing affects all packets that match its interface specs.

I could be wrong about this being the rule that's stopping the traffic, but a visit to the IP → Firewall → Filter Rules tab should prove enlightening. With the network idle, the Packets column should tell you which rule was the last to see these broadcast packets. If they're not making it all the way through to an "accept" action, there's your problem.

I have no problem with receiving of multicast traffic on remote side.

Multicast and broadcast are very different things, subject to different rules. The only way they're not going to behave differently is if you have a newbie configuration mistake called multicast flooding. It is good that you have not done that.
 
shilov
just joined
Topic Author
Posts: 5
Joined: Wed Jul 07, 2021 10:42 pm

Re: Ethernet Broadcast packets on CRS125

Fri Jul 09, 2021 1:47 pm

Thanks again!
"drop all from WAN" works only for incoming packets?
No, look at the rule: chain=forward, in-interface-list=WAN
What we don't know — because you haven't told us! — is whether the WAN is involved at all. If these two routers are on opposite sides of the WAN link, then yes, packets being forwarded through the router from the WAN will be subject to this rule.
Please look closer to section '/interface list member' - there is no interfaces in WAN list.

What is "2T"?
It means VLAN2 Tagged.

Okay, so are the packets transiting the WAN link at all, or are they getting stopped before they get there?
If you don't know, don't guess. Use the router's Torch or Packet Sniffer tool on the inbound and outbound interfaces separately to find out for certain.
Yes, I did that:
I did Packet Capture on SW2 port ether2 and I can see UDP packets to 0.0.0.0:bootps (ethernet broadcast) coming from Client.
And I didn't see this kind of packets on ether1.

And by the way...
The rule I'm citing affects all packets that match its interface specs.

I could be wrong about this being the rule that's stopping the traffic, but a visit to the IP → Firewall → Filter Rules tab should prove enlightening. With the network idle, the Packets column should tell you which rule was the last to see these broadcast packets. If they're not making it all the way through to an "accept" action, there's your problem.
I don't understand why you all payng such attention to IP/Firewall rules.
We are talking about bridge/switch and L2 traffic.
I'm not using 'use-ip-firewall' option in bridge section. It's set to 'no' by default. So L2 not goes to Firewall.
Also I use no bridge VLAN filtering.
And there is option 'broadcast-flood' for '/interface bridge port' - it's set to 'yes' by default. So CRS125 have to flood this traffic to ether1.
 
tangent
Forum Guru
Forum Guru
Posts: 1351
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Ethernet Broadcast packets on CRS125

Fri Jul 09, 2021 3:11 pm

Please look closer to section '/interface list member' - there is no interfaces in WAN list.

You really should cut this configuration down to the minimal setup that demonstrates the problem. All this superfluous noise is confusing matters needlessly.

I don't understand why you all payng such attention to IP/Firewall rules.

I might very well be off on a wild tangent; check the user name! It just seems like a valid thing to try given that you have "drop" rules in that firewall.

You don't have to take my guesses as gospel. Put a line like this into the top of your firewall, then move it down until the counter stops incrementing each time you force a DHCP renewal on the client:

/ip firewall filter
add action=log chain=input in-interface=bridge1 port=68 protocol=udp

We are talking about bridge/switch and L2 traffic. I'm not using 'use-ip-firewall' option in bridge section. It's set to 'no' by default. So L2 not goes to Firewall.

UDP broadcast traffic is L3, so the L3 firewall still applies if your traffic takes the bridge input path rather than the bridge forward path. I'm not certain, but I think your packets take both paths: forward from ether2, where it gets broadcast flooded, then input to ether1.

That is to say, I believe your DHCP traffic is taking the A → B → I path in the packet flow diagram, sending it through this firewall chain.

If it didn't work this way, you couldn't apply firewall rules to DHCP traffic flowing through at all. Since I have in fact done that very thing my MT switches here as part of an effort to come up with a better DHCP starvation mitigation, I do believe the traffic takes the L3 filtering path even in cases like yours.

Given that you've eliminated the dstnat WAN rule as a possibility, I went searching for another "drop" rule that could do this and came up with only one: the "!LAN" rule. I then went looking to see what's in the "LAN" list, and it's only "bridge1". Are you sure a firewall can match on the bridge itself? All the examples I can find show the physical interfaces being added to the list individually.

You don't have to answer that question from first principles. Just put that firewall logging rule into your filter list and move it down the list until the counter stops increasing. If it stops at the !LAN rule, then I was right. If not, then let us know that and we'll keep searching for answers.
 
tdw
Forum Guru
Forum Guru
Posts: 1843
Joined: Sat May 05, 2018 11:55 am

Re: Ethernet Broadcast packets on CRS125

Fri Jul 09, 2021 3:57 pm

UDP broadcast traffic is L3, so the L3 firewall still applies if your traffic takes the bridge input path rather than the bridge forward path. I'm not certain, but I think your packets take both paths: forward from ether2, where it gets broadcast flooded, then input to ether1.
No it is a UDP IP packet sent to the ethernet broadcast address. As such it will appear in both bridge input (to the Mikrotik itself) and bridge forward (to other bridge ports) paths. The /ip firewall filter will then process the packets destined for the Mikrotik itself, but not the bridge forwarded packets unless use-ip-firewall=yes is set.

Switched unicast traffic to a known destination MAC address doesn't even hit the bridge, it is handed internally by the switch chip and can be processed with switch rules.

you couldn't apply firewall rules to DHCP traffic flowing through at all.
As an aside you can't apply /ip firewall filter rules to DHCP traffic handled by the Mikrotik itself - the counters on a drop rule would increment, but the DHCP server will still receive and process the packets as it uses a raw, not udp IP socket.

But back to the OP's issue, yes it would be best to remove all of the unnecessary bridges, interface lists, firewall rules, etc.

Who is online

Users browsing this forum: Amazon [Bot], Bing [Bot], iustin and 88 guests