[Dnsmasq-discuss] IP address based on switch port number (option 82)

richardvoigt at gmail.com richardvoigt at gmail.com
Sun Feb 14 23:05:00 GMT 2010


On Sun, Feb 14, 2010 at 4:56 PM, <Ignacio.Bravo at belden.com> wrote:

>
>
> >>ebtables or iptables can be used to match the source MAC address and
> >>only accept inbound DHCP requests from the relay(s).  No change needed
> >>to dnsmasq.
>
> I did that also with Iptables and it works. But there is a drawback: Not
> all ports really need option 82 (you can activate this switch function per
> port so that some ports have a fixed IP and some others not)
> In that general case dnsmasq should receive broadcasts and unicasts. Only
> some broadcasts should be discarded!
>

I should think you'd want to do that configuration -- assign some ports
fixed IPs and let others draw from the pool -- in the dnsmasq configuration
instead of at the switch.


>
> I feel a good idea not checking circuit-remote ID tags on DHCP requests
> (not only renewals), what do you think? doing this no problem with renewals
> nor L2 relays. L3 relays would filter the broadcasts and this change would
> not disturb (i may be wrong...)
>
> Should you be interested in captures from hanewin dhcp server in the same
> scenario please let me know
>
> by the way, ISC also loops in this situation
>
> Simon: Of course I am eager to check any new code you could provide. I am a
> newbie in linux, may you please (if possible) detail commands/tools I should
> do/have to make&install any possible code? I am on ubuntu
>

With ubuntu it should be very easy to try code changes.  Dnsmasq is also
used on lots of small routers where it is included in the firmware, requires
a cross-compiler to update, and is generally more of a pain.


>
> Thanks again
> Ignacio
>
>
>
>  From:
> "richardvoigt at gmail.com" <richardvoigt at gmail.com>
> To:
> Simon Kelley <simon at thekelleys.org.uk>
> Cc: Ignacio.Bravo at belden.com, dnsmasq-discuss at lists.thekelleys.org.uk
> Date: 14/02/2010 21:02
>  Subject: Re: [Dnsmasq-discuss] IP address based on switch port number
> (option         82)
> ------------------------------
>
>
>
> On Sun, Feb 14, 2010 at 1:53 PM, Simon Kelley <simon at thekelleys.org.uk>
> wrote:
> > Ignacio.Bravo at belden.com wrote:
> >> Hello Simon, Thanks fo such a quick answer! Yes I detected that a bit
> >> later and the tag is set now.
> >> dhcp-range=net:ignacio,10.10.35.60,10.10.35.65
> >> dhcp-circuitid=ignacio,b9:06:00:00:01:01:01:03,
> >> dhcp-remoteid=ignacio,00:06:00:80:63:60:e1:64
> >>
> >> BUT IT STILL DOESNT WORK. the tag is set but i detected sort of a
> >> loop of discovers, NAKs and ACKs so that client does never get its IP
> >>  Please find enclosed log output (dnsmasq shows loop.txt) Every
> >> "dnsmasq: etiquetas: ignacio, eth0" tag is set (Spanish log, sorry)
> >>
> >> Please find enclosed capture file showing the loop (dhcp loop from
> >> wireshark at the server side): Relay: .251 server: .200
> >>
> >> Please take into account I have a layer2 network (client----L2switch
> >> acting as dhcp relay op82---dhcp server)
> >>
> >> I feel the problem is dnsmasq receives two requests at almost the
> >> same time (the broadcasted one which is Naked and the unicasted one
> >> Acked) Of course the NACk message restarts the process at the client
> >> side
> >
> >>
> >> Two questions: - Do you have any dnsmasq config solution for that
> >> (what´s the reason for the first request to be NAKed?)? I have
> >> experience with Hanewin and works ok in this topology without
> >> 'external help' I got one solution using iptables -A INPUT -i eth0 -p
> >> udp -s 0.0.0.0/32 -d 255.255.255.255/32 --dport 67 -j DROP (i do
> >> filter any broadcasted request or discover)
> > You are right. It's getting one request direct (without going through
> > the relay in the switch) and one request from the relay. Only the
> > request that goes throught switch has the circuit-id and sets the tag.
> > Without the tag, the dhcp-range is not avilable, so it causes an error.
> >
> > Part of this problem is the strange setup you have where the clients are
> > in the same broadcast domain as the server, _and_ you have the DHCP
> > relay. Even without that there's still a problem because clients will do
> > DHCP renewals direct/unicast without using the relay - that will fail.
> >
> > Some switches can be configured to do transparent option-82 addition to
> > _all_ DHCP packets without doing the relay function. That would fix the
> > problem if your switch can do it.
> >
> > I'm going to have to think about code changes to fix this in the general
> > case. Are you able to compile and test new versions of dnsmasq?
>
> ebtables or iptables can be used to match the source MAC address and
> only accept inbound DHCP requests from the relay(s).  No change needed
> to dnsmasq.
>
> >
> >> - does dnsmasq.conf do an AND with dhcp-circuitid
> > dhcp-remoteid values?, I mean,
> >> should I have more than one switch could dnsmasq sort the first port
> >> of the first switch and the first port at the second switch?
> >
> > Yes, you can do that: The AND function is in dhcp-range: set tags for
> > each switch and port and use a switch tag and a port tag in dhcp-range
> >
> > dhcp-range=net:switch-1,net:port-1,192.168.7.1,192.168.7.4,255.255.255.0
> >
> > Cheers,
> >
> > Simon.
> >
> > _______________________________________________
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss at lists.thekelleys.org.uk
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >
>
>
> DISCLAIMER: Privileged and/or Confidential information may be contained in
> this message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you should
> destroy the message and kindly notify the sender by reply e-mail. It is
> understood that opinions or conclusions that do not relate to the official
> business of the company are neither given nor endorsed by the company. Thank
> You.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20100214/43a33248/attachment-0001.htm 


More information about the Dnsmasq-discuss mailing list