X-RT-Original-Encoding: utf-8 Content-Transfer-Encoding: base64 content-type: text/plain; charset="utf-8" Content-Length: 6000 Hi, obviously nobody really looked into this issue. May be forgotten or overseen. May be you find time to check this issue. Immo This message has been classified General Business by IMMO WETZEL on Sonntag, 25. Februar 2018 at 23:18:44. From: DHCP Bugs via RT [mailto:dhcp-confidential@isc.org] Sent: Monday, January 29, 2018 6:47 PM To: IMMO WETZEL Subject: [ISC-Bugs #47077] AutoReply: dhcrelay relays packages which are already handled from same host different relay Greetings, This message was automatically generated to acknowledge receipt of your recent email "dhcrelay relays packages which are already handled from same host different relay", and to let you know that we have opened a ticket for your request (a summary of which appears below.) We do not need a further response from you at this time, but if you do respond, please include in the Subject of your reply the ID '[ISC-Bugs #47077]' so that we can match up your reply with the ticket in our system. What Happens Next ================= Bug reports submitted to us in this manner are handled based on perceived severity in relation to other bugs. We handle reports as time permits so there is no guaranteed response time for these reports. If you feel the issue you are reporting is a security issue, please see http://www.isc.org/security/reporting-issues for details on how to report it, including the PGP key you may use. If it is of a non-security yet still urgent matter, you may reply to this message to add further information. Public Visibility of Bugs ========================= Most bind and dhcp bug reports submitted since July 7, 2017 are visible to the public at https://bugs.isc.org > after review by the developers. If you want this report to be withheld from public view, please reply to this message with your request. All reports submitted to bind9-confidential@isc.org and dhcp-confidential@isc.org are withheld from public view. Other Support Options ===================== If your organization requires more immediate attention, ISC offers paid support options. Please see http://www.isc.org/services/support for more information. If paid support is not an option, please consider making a donation to ISC. We don't require a donation -- we will work on your report just as quickly whether or not you can donate -- but we always need and welcome community support. See http://www.isc.org/supportisc Run a Supported Version ======================= If you are not running a supported version of our software, please upgrade. Bug reports against unsupported versions of BIND are discouraged, as your issue may have already been addressed. You can find the latest versions of our software here: https://www.isc.org/downloads/ For configuration help... ========================= Questions regarding configuration or setup are addressed on mailing lists - to subscribe, visit: https://lists.isc.org/mailman/listinfo/bind-users or https://lists.isc.org/mailman/listinfo/dhcp-users Thank you, dhcp-confidential@isc.org --------------------------------------------------------------------- Hi, I do run dhcrelay inside a docker container attached to the host network. And I do it twice. a) dhcrelay -4 -d -m discard -iu ens18 -id br_TB102_TMN 10.160.5.2 a) dhcrelay -4 -d -iu br_TB102_TMN -id br_TB102_DPU 10.160.50.18 both are up and listen Requesting: ens18 as upstream: Y downstream: N Requesting: br_TB102_TMN as upstream: N downstream: Y Internet Systems Consortium DHCP Relay Agent 4.3.6 Copyright 2004-2017 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/br_TB102_TMN/7a:59:88:45:a6:23 Sending on LPF/br_TB102_TMN/7a:59:88:45:a6:23 Listening on LPF/ens18/36:78:14:96:53:13 Sending on LPF/ens18/36:78:14:96:53:13 Sending on Socket/fallback Forwarded BOOTREQUEST for 00:19:92:c6:9d:b6 to 10.160.5.2 Forwarded BOOTREQUEST for 00:19:92:c6:9d:b6 to 10.160.5.2 Dropping request received on ens18 Dropping request received on ens18 Forwarded BOOTREQUEST for 00:19:92:c6:9d:b6 to 10.160.5.2 Forwarded BOOTREQUEST for 00:19:92:c6:9d:b6 to 10.160.5.2 Dropping request received on ens18 Dropping request received on ens18 Requesting: br_TB102_TMN as upstream: Y downstream: N Requesting: br_TB102_DPU as upstream: N downstream: Y Internet Systems Consortium DHCP Relay Agent 4.3.6 Copyright 2004-2017 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/br_TB102_DPU/42:b9:9b:1e:1c:c9 Sending on LPF/br_TB102_DPU/42:b9:9b:1e:1c:c9 Listening on LPF/br_TB102_TMN/7a:59:88:45:a6:23 Sending on LPF/br_TB102_TMN/7a:59:88:45:a6:23 Sending on Socket/fallback Forwarded BOOTREQUEST for 00:19:92:c6:9d:b6 to 10.160.50.18 Forwarded BOOTREQUEST for 00:19:92:c6:9d:b6 to 10.160.50.18 But the frames which should be forwarded by relay b) only to 10.160.50.18 are also taken from the second dhcrelay a) and forwarded to 10.160.5.2 I don't see the frames from server a) 10.160.50.18 at the relay b) downstream side. So it has to do with the listen side. How can I prevent this shit ? Or how to setup a two relay linux router ? Immo This message has been classified General Business by IMMO WETZEL on Montag, 29. Januar 2018 at 18:44:37.