Re: Dropping reply received on <downstream interface> when using -iu/-id

[Brian J. Murrell]

On Tue, 2017-12-12 at 09:54 -0500, Brian J. Murrell wrote:

> I want to use the -iu/-id options with dhcrelay to prevent relays
> from
> relaying (and thus duplicating) requests coming from the network that
> the DHCP server is on[1]:
>
> # /usr/sbin/dhcrelay -4 -d -pf /var/run/dhcrelay4.pid -id br-guest
> -iu br-lan 10.75.22.247
>
> When I do this, DHCP Discover requests coming from clients on the br-
> guest interface have their Relay agent IP address set to the address
> of
> the br-guest interface.  When the DHCP server sends back an DHCP
> Offer
> it sends it to the IP address of the br-guest interface on the relay
> machine.  dhcrelay then proceeds to drop that reply:
>
> Dropping reply received on br-guest
>
> Is there something I am misunderstanding about how -iu/-id are
> supposed
> to work?
>
> Cheers,
> b.
>
> [1] I'm surprised this is not implicit to be honest.  The relay knows
> which network the server is on.  Why is it relaying requests that
> come
> from that network to that network?

Any ideas about this?

b.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Patrick Cervicek]

Am 2. Januar 2018 15:55:52 MEZ schrieb "Brian J. Murrell" <[hidden email]>:

>On Tue, 2017-12-12 at 09:54 -0500, Brian J. Murrell wrote:
>> I want to use the -iu/-id options with dhcrelay to prevent relays
>> from
>> relaying (and thus duplicating) requests coming from the network that
>> the DHCP server is on[1]:
>>
>> # /usr/sbin/dhcrelay -4 -d -pf /var/run/dhcrelay4.pid -id br-guest
>> -iu br-lan 10.75.22.247
>>
>> When I do this, DHCP Discover requests coming from clients on the br-
>> guest interface have their Relay agent IP address set to the address
>> of
>> the br-guest interface.  When the DHCP server sends back an DHCP
>> Offer
>> it sends it to the IP address of the br-guest interface on the relay
>> machine.  dhcrelay then proceeds to drop that reply:
>>
>> Dropping reply received on br-guest
>>

To me it looks like DHCP Offer did come in via br-guest (and not br-lan)
Are this interfaces seperated or somehow bridged together? Locally or on the same switch/vlan
The server should be reachable only via br-lan

Could you provide:
brctl show br-guest
brctl show br-lan
ip addr

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Brian J. Murrell]

On Wed, 2018-01-03 at 00:47 +0100, Patrick Cervicek wrote:
>
> To me it looks like DHCP Offer did come in via br-guest (and not br-
> lan)

Which is not right.

> Are this interfaces seperated or somehow bridged together?

They are separate.  No bridging between them.  They themselves are
bridges but not together:

# brctl show
bridge name bridge id STP enabled interfaces
br-guest 7fff.f250d105d430 no eth0.15
                                                        wlan1-1
                                                        wlan0-1
br-lan 7fff.6cb0cef51e4a no eth0.1
                                                        wlan1
                                                        wlan0

> Locally or on the same switch/vlan

I think I know where you are going and I would tend to hold bridge
and/or vlan leaks among the lowest of probabilities of causes here.  I
seem to recall tcpdump showing me that DHCP packets were moving in the
correct directions also.

> The server should be reachable only via br-lan

Right.  It is.

> Could you provide:
> brctl show br-guest
> brctl show br-lan

As above.

> ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether f2:50:d1:05:d4:30 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::f050:d1ff:fe05:d430/64 scope link
       valid_lft forever preferred_lft forever
6: br-guest: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether f2:50:d1:05:d4:30 brd ff:ff:ff:ff:ff:ff
    inet 192.168.101.252/24 brd 192.168.101.255 scope global br-guest
       valid_lft forever preferred_lft forever
    inet 192.168.101.254/24 brd 192.168.101.255 scope global secondary br-guest
       valid_lft forever preferred_lft forever
    inet6 fe80::f050:d1ff:fe05:d430/64 scope link
       valid_lft forever preferred_lft forever
7: eth0.15@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-guest state UP group default qlen 1000
    link/ether f2:50:d1:05:d4:30 brd ff:ff:ff:ff:ff:ff
8: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 6c:b0:ce:f5:1e:4a brd ff:ff:ff:ff:ff:ff
    inet 10.75.22.252/24 brd 10.75.22.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet 10.75.22.254/24 scope global secondary br-lan
       valid_lft forever preferred_lft forever
    inet6 fe80::6eb0:ceff:fef5:1e4a/64 scope link
       valid_lft forever preferred_lft forever
9: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
    link/ether 6c:b0:ce:f5:1e:4a brd ff:ff:ff:ff:ff:ff
12: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
    link/ether 6c:b0:ce:f5:1e:4c brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6eb0:ceff:fef5:1e4c/64 scope link
       valid_lft forever preferred_lft forever
14: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
    link/ether 6c:b0:ce:f5:1e:4a brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6eb0:ceff:fef5:1e4a/64 scope link
       valid_lft forever preferred_lft forever
16: wlan1-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-guest state UP group default qlen 1000
    link/ether 6e:b0:ce:f5:1e:4c brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6cb0:ceff:fef5:1e4c/64 scope link
       valid_lft forever preferred_lft forever
17: wlan0-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-guest state UP group default qlen 1000
    link/ether 6e:b0:ce:f5:1e:4a brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6cb0:ceff:fef5:1e4a/64 scope link
       valid_lft forever preferred_lft forever

Cheers,
b.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Patrick Cervicek]

> I
> seem to recall tcpdump showing me that DHCP packets were moving in the
> correct directions also.

Could you check tcpdump on your relay host as follow please:

#1
tcpdump -i br-lan host 10.75.22.247 and udp port 67

#2
tcpdump -i br-guest host 10.75.22.247 and udp port 67

with #1 you should only see message between your relay host and server



_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Brian J. Murrell]

On Thu, 2018-01-04 at 18:41 +0100, Patrick Cervicek wrote:

>
> Could you check tcpdump on your relay host as follow please:
>
> #1
> tcpdump -i br-lan host 10.75.22.247 and udp port 67
>
> #2
> tcpdump -i br-guest host 10.75.22.247 and udp port 67
>
> with #1 you should only see message between your relay host and
> server

Interestingly, I went to reproduce my issue to gather this info and now
it's working.  I don't think anything has changed that would enable to
start working now when it was not before, but I guess I shouldn't look
a gift horse in the mouth.

Cheers,
b.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users