2

Linux system with two NICs.

  1. eth0 connected to Co. LAN. DHCP configured. It is the main network connection.
  2. eth1 point-to-point connected to a network analyzer. No IP on this interface.
  3. Linux application sending L2 packets on eth1.
  4. The network analyzer gets the application packets PLUS all broadcasts arrived on eth0.

Question: How can I stop broadcasts being forwarded on eth1 ?

Config:

eth0 Link encap:Ethernet HWaddr 10:98:36:af:9c:0f
inet addr:192.168.x.xx Bcast:192.168.3.255 Mask:255.255.252.0 UP
BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

eth1 Link encap:Ethernet HWaddr 10:98:36:af:9c:10
UP BROADCAST RUNNING MTU:1500 Metric:1

ip link:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:0f brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:10 brd ff:ff:ff:ff:ff:ff
Hauke Laging
  • 88,146
  • 18
  • 125
  • 174
papy muzo
  • 21
  • 1
  • 2
  • What is the output of `ip link`? Does this happen when the application is not running, too? – Hauke Laging Aug 09 '17 at 20:02
  • It does happen permanently, app or noapp. – papy muzo Aug 09 '17 at 20:35
  • 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:0f brd ff:ff:ff:ff:ff:ff 3: eth1: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:10 brd ff:ff:ff:ff:ff:ff – papy muzo Aug 09 '17 at 20:36
  • 1
    The HWaddr suggests that both eth IFs are part of the same hardware device. Maybe that device is bridging them internally? Can you add details about the ethernet hardware and the Linux system to the question? – dirkt Aug 10 '17 at 06:10
  • DELL PowerEdge T130. Linux 4.4.0-62-generic #83-Ubuntu SMP . – papy muzo Aug 10 '17 at 14:00
  • network: eth0 Broadcom NetXtreme BCM5720 Gigabit Ethernet PCIe eth1 Broadcom NetXtreme BCM5720 Gigabit Ethernet PCIe – papy muzo Aug 10 '17 at 14:05
  • Note: This is the __NORMAL__ behavior of the Network Stack. Both, physical interfaces are part of the same SW Stack and broadcasts must go through. I am looking for a way to stop that and fully isolate eth1 from eth0. – papy muzo Aug 10 '17 at 14:10
  • What makes you think this was the normal behaviour? This does not happen on my system. It is explicitly forbidden for interfaces which are in different subnets. – Hauke Laging Aug 10 '17 at 18:47
  • eth1 is not part of any subnet. There is no IP, no mask and no broadcast address on this port. However all ff-ff-ff-ff-ff-ff, which are L2 broadcasts go through. – papy muzo Aug 10 '17 at 23:19
  • Did you tried just disabling the `BROADCAST` flag on the concerned interface (aka `ifconfig eth1 -broadcast`) ? – binarym Jan 24 '20 at 16:31

1 Answers1

0

Fixed the problem by adding two rules to iptables:

iptables -A FORWARD -m pkttype --pkt-type broadcast -i eth1 -j DROP  
iptables -A INPUT -m pkttype --pkt-type broadcast -i eth1 -j DROP

Iptables looks now:

$ iptables -L -v  
Chain INPUT (policy ACCEPT 54446 packets, 5132K bytes)
 pkts bytes target     prot opt in     out     source               destination         
  123 40344 DROP       all  --  eth1   any     anywhere             anywhere             PKTTYPE = broadcast

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  eth1   any     anywhere             anywhere             PKTTYPE = broadcast

Chain OUTPUT (policy ACCEPT 8072 packets, 3990K bytes)
 pkts bytes target     prot opt in     out     source               destination
Paolo
  • 16,955
  • 11
  • 31
  • 40
papy muzo
  • 21
  • 1
  • 2
  • I'm still very much confused why broadcasts are forwarded in the first place - the default behaviour is that they aren't. The fact that you can disable it through `iptables` means the broadcasts are forwarded through the Linux kernel, which means you must run some software or have enabled something that does the forwarding in the first place. If you can find out what this is, you can disable it directly instead of using `iptables`. – dirkt Aug 11 '17 at 05:02
  • Could you, please provide a pointer to some doc which describes the default behavior. I was not able to find any. – papy muzo Aug 11 '17 at 15:38
  • I don't think this is explicitely mentioned in any docs, but that's what happens on my system, and on any other system I've seen so far. Normally *nothing* is forwarded between different network interfaces unless they are bridged. There's plenty of questions how to *enable* forwarding broadcasts, e.g. [here](https://serverfault.com/questions/744335/how-to-forward-ipv4-broadcast-packets-between-2-computers-on-2-different-subnets) or [here](https://serverfault.com/questions/276596/forward-broadcast-to-fixed-ip-using-iptables) (google for more). – dirkt Aug 12 '17 at 05:31
  • Actually, the second answers mentioned `ebtables`, so one idea is to check if something was configured using `ebtables` (like `iptables`, but on OSI Level 2) on your system. – dirkt Aug 12 '17 at 05:32
  • Mainly what I saw were "bootp" or "dhcp" requests. They are pure L2 broadcasts supposed to be LAN wide. eth0 gets them as being LAN connected. eth1 does not have an IP - it is not in an IP broadcast domain but it is in a LAN. As long as eh1 is down you do not see these packets. Connecting eth1 to some other Ethernet port both link-up. I suppose the Linux network stack (won't say IP stack) assumes same LAN and in consequence will forward them. As soon as you attach a different LAN IP on eth1 this behavior stops. HW took the system to keep working on their stuff. I, no longer can experiment. – papy muzo Aug 14 '17 at 18:05