Hi, i'm using kea-dhcp4 version 1.1.0 from epel repo.
Here is tcpdump: 13:35:31.734452 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 335) x.x.x.156.67 > x.x.x.90.67: [udp sum ok] BOOTP/DHCP, Request from f4:8b:32:a3:79:3f, length 307, hops 1, xid 0x88cd169e, secs 2, Flags [none] (0x0000) Gateway-IP 100.101.101.1 Client-Ethernet-Address f4:8b:32:a3:79:3f Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether f4:8b:32:a3:79:3f MSZ Option 57, length 2: 1500 Vendor-Class Option 60, length 18: "android-dhcp-6.0.1" Hostname Option 12, length 17: "MINOTELTE-MiPhone" Parameter-Request Option 55, length 9: Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name MTU, BR, Lease-Time, RN RB 13:35:31.736533 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 330) x.x.x.90.67 > 100.101.101.1.67: [udp sum ok] BOOTP/DHCP, Reply, length 302, hops 1, xid 0x88cd169e, Flags [none] (0x0000) Your-IP 100.101.101.132 Gateway-IP 100.101.101.1 Client-Ethernet-Address f4:8b:32:a3:79:3f Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 100.101.101.1 Domain-Name-Server Option 6, length 4: x.x.x.10 Hostname Option 12, length 17: "MINOTELTE-MiPhone" Lease-Time Option 51, length 4: 86400 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: x.x.x.90 Client-ID Option 61, length 7: ether f4:8b:32:a3:79:3f Agent's giaddr is not reachable by server, why it keeps sending replies to it? Is there an option to reply to packet's source address? _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
On 28.09.2017 11:14, Sergey Klusov wrote:
> Hi, i'm using kea-dhcp4 version 1.1.0 from epel repo. > Here is tcpdump: > > 13:35:31.734452 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto > UDP (17), length 335) > x.x.x.156.67 > x.x.x.90.67: [udp sum ok] BOOTP/DHCP, Request from > f4:8b:32:a3:79:3f, length 307, hops 1, xid 0x88cd169e, secs 2, Flags > [none] (0x0000) > Gateway-IP 100.101.101.1 > Client-Ethernet-Address f4:8b:32:a3:79:3f > Vendor-rfc1048 Extensions > Magic Cookie 0x63825363 > DHCP-Message Option 53, length 1: Discover > Client-ID Option 61, length 7: ether f4:8b:32:a3:79:3f > MSZ Option 57, length 2: 1500 > Vendor-Class Option 60, length 18: "android-dhcp-6.0.1" > Hostname Option 12, length 17: "MINOTELTE-MiPhone" > Parameter-Request Option 55, length 9: > Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name > MTU, BR, Lease-Time, RN > RB > 13:35:31.736533 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto > UDP (17), length 330) > x.x.x.90.67 > 100.101.101.1.67: [udp sum ok] BOOTP/DHCP, Reply, > length 302, hops 1, xid 0x88cd169e, Flags [none] (0x0000) > Your-IP 100.101.101.132 > Gateway-IP 100.101.101.1 > Client-Ethernet-Address f4:8b:32:a3:79:3f > Vendor-rfc1048 Extensions > Magic Cookie 0x63825363 > Subnet-Mask Option 1, length 4: 255.255.255.0 > Default-Gateway Option 3, length 4: 100.101.101.1 > Domain-Name-Server Option 6, length 4: x.x.x.10 > Hostname Option 12, length 17: "MINOTELTE-MiPhone" > Lease-Time Option 51, length 4: 86400 > DHCP-Message Option 53, length 1: Offer > Server-ID Option 54, length 4: x.x.x.90 > Client-ID Option 61, length 7: ether f4:8b:32:a3:79:3f > > Agent's giaddr is not reachable by server, why it keeps sending replies > to it? > Is there an option to reply to packet's source address? > _______________________________________________ > Kea-users mailing list > [hidden email] > https://lists.isc.org/mailman/listinfo/kea-users From RFC2131: "If the 'giaddr' field in a DHCP message from a client is non-zero, the server sends any return messages to the 'DHCP server' port on the BOOTP relay agent whose address appears in 'giaddr'." I read this as the server is doing what it is supposed to do. Marcin _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
Okay, thanks. But is there an option to change that behavior?
On Чт 28.09.2017 14:24, Marcin Siodelski wrote: > >From RFC2131: > "If the 'giaddr' field in a DHCP message from a client is non-zero, > the server sends any return messages to the 'DHCP server' port on the > BOOTP relay agent whose address appears in 'giaddr'." > > I read this as the server is doing what it is supposed to do. > > Marcin > _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
IMHO the simplest is to write a little hook which resets the giaddr,
or to understand why the client or relay sets it and fix this. Regards Francis Dupont <[hidden email]> _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
On Чт 28.09.2017 14:37, Francis Dupont wrote:
> IMHO the simplest is to write a little hook which resets the giaddr, > or to understand why the client or relay sets it and fix this. > > Regards > > Francis Dupont <[hidden email]> > Client is a mikrotik router with some specific setup: lan segment which it runs relay for is in VRF instance, but there is a limitation in RouterOS that dhcp-relay destination will be contacted using main routing table. Because of that, relay messages are sent out-of-band, using different interface. Right now i'm working on supplying additional option 82 information to kea, by wich it should select appropriate subnet. 14:30:40.033857 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 360) x.x.x.156.67 > x.x.x.90.67: [udp sum ok] BOOTP/DHCP, Request from f4:8b:32:a3:79:3f, length 332, hops 1, xid 0xa111bece, secs 17, Flags [none] (0x0000) Gateway-IP x.x.x.156 Client-Ethernet-Address f4:8b:32:a3:79:3f Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether f4:8b:32:a3:79:3f MSZ Option 57, length 2: 1500 Vendor-Class Option 60, length 18: "android-dhcp-6.0.1" Hostname Option 12, length 17: "MINOTELTE-MiPhone" Parameter-Request Option 55, length 9: Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name MTU, BR, Lease-Time, RN RB Agent-Information Option 82, length 23: Circuit-ID SubOption 1, length 6: M-~^K.M-AM-tz Remote-ID SubOption 2, length 13: 100.101.101.0 Can someone tell me how to make kea select subnet 100.101.101.0/24 by Remote-ID "100.101.101.0" suboption and giaddr? Should i define some class and apply it to subnet? _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
A client class is the easiest way to perform specific subnet selection.
Regards Francis Dupont <[hidden email]> _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
On Чт 28.09.2017 15:16, Francis Dupont wrote:
> A client class is the easiest way to perform specific subnet selection. > > Regards > > Francis Dupont <[hidden email]> > . > Trying this way, but does not work: "client-classes": [ { "name": "routed_100_101_101_0_24", "test": "relay4[2].text == '100.101.101.0'" } ], 2017-09-28 15:27:31.459 DEBUG [kea-dhcp4.packets/4408] DHCP4_BUFFER_RECEIVED received buffer from x.x.x.156:67 to x.x.x..90:67 over interface lan0.96 2017-09-28 15:27:31.460 DEBUG [kea-dhcp4.options/4408] DHCP4_BUFFER_UNPACK parsing buffer received from x.x.x.156 to x.x.x.90 over interface lan0.96 2017-09-28 15:27:31.460 DEBUG [kea-dhcp4.eval/4408] EVAL_DEBUG_OPTION Pushing option 2 with value 'type=002, len=013: 31:30:30:2e:31:30:31:2e:31:30:31:2e:30' 2017-09-28 15:27:31.460 DEBUG [kea-dhcp4.eval/4408] EVAL_DEBUG_STRING Pushing text string '100.101.101.0' 2017-09-28 15:27:31.460 DEBUG [kea-dhcp4.eval/4408] EVAL_DEBUG_EQUAL Popping 0x3130302E3130312E3130312E30 and 0x747970653D3030322C206C656E3D3031333A2033313A33303A33303A32653A33313A33303A33313A32653A33313A33303A33313A32653A3330 pushing result 'false' 2017-09-28 15:27:31.460 DEBUG [kea-dhcp4.options/4408] EVAL_RESULT Expression routed_100_101_101_0_24 evaluated to 0 2017-09-28 15:27:31.460 DEBUG [kea-dhcp4.packets/4408] DHCP4_PACKET_RECEIVED [hwtype=1 74:23:44:5d:44:4a], cid=[01:74:23:44:5d:44:4a], tid=0xb9926426: DHCPDISCOVER (type 1) received from x.x.x.156 to x.x.x.90 on interface lan0.96 2017-09-28 15:27:31.460 DEBUG [kea-dhcp4.packets/4408] DHCP4_QUERY_DATA [hwtype=1 74:23:44:5d:44:4a], cid=[01:74:23:44:5d:44:4a], tid=0xb9926426, packet details: local_address=x.x.x.90:67, remote_adress=x.x.x.156:67, msg_type=DHCPDISCOVER (1), transid=0xb9926426, options: type=012, len=018: "RedmiNote3-xrn3pro" (string) type=053, len=001: 1 (uint8) type=055, len=009: 1(uint8) 3(uint8) 6(uint8) 15(uint8) 26(uint8) 28(uint8) 51(uint8) 58(uint8) 59(uint8) type=057, len=002: 1500 (uint16) type=060, len=018: "android-dhcp-6.0.1" (string) type=061, len=007: 01:74:23:44:5d:44:4a type=082, len=023:, options: type=001, len=006: fe:0b:2e:c1:f4:7a type=002, len=013: 31:30:30:2e:31:30:31:2e:31:30:31:2e:30 2017-09-28 15:27:31.461 DEBUG [kea-dhcp4.packets/4408] DHCP4_SUBNET_SELECTION_FAILED [hwtype=1 74:23:44:5d:44:4a], cid=[01:74:23:44:5d:44:4a], tid=0xb9926426: failed to select subnet for the client 2017-09-28 15:27:31.461 DEBUG [kea-dhcp4.dhcp4/4408] DHCP4_CLASS_ASSIGNED [hwtype=1 74:23:44:5d:44:4a], cid=[01:74:23:44:5d:44:4a], tid=0xb9926426: client packet has been assigned to the following class(es): VENDOR_CLASS_android-dhcp-6.0.1 _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
"test": "relay4[2].text == '100.101.101.0'"
=> please try "test": "relay4[2].hex == 100.101.101.0" (.text does not return what you want if the (sub-)option is not a string and IP address litterals are supported). Regards Francis Dupont <[hidden email]> _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
On Чт 28.09.2017 16:09, Francis Dupont wrote:
> "test": "relay4[2].text == '100.101.101.0'" > > => please try "test": "relay4[2].hex == 100.101.101.0" > (.text does not return what you want if the (sub-)option is not a string > and IP address litterals are supported). > > Regards > > Francis Dupont <[hidden email]> > For now it works this way "relay4[2].hex==0x3130302e3130312e3130312e30", but it rather clumsy. Mikrotik does not allow to specify binary value either. Some function like relay4[2].string would be nice. _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
On 28.09.2017 13:22, Sergey Klusov wrote:
> On Чт 28.09.2017 16:09, Francis Dupont wrote: >> "test": "relay4[2].text == '100.101.101.0'" >> >> => please try "test": "relay4[2].hex == 100.101.101.0" >> (.text does not return what you want if the (sub-)option is not a string >> and IP address litterals are supported). >> >> Regards >> >> Francis Dupont <[hidden email]> >> > Didn't work, because it converts 100.101.101.0 into 4-byte IP address. > > For now it works this way "relay4[2].hex==0x3130302e3130312e3130312e30", > but it rather clumsy. > > Mikrotik does not allow to specify binary value either. > > Some function like relay4[2].string would be nice. > > > _______________________________________________ > Kea-users mailing list > [hidden email] > https://lists.isc.org/mailman/listinfo/kea-users Perhaps it will be better to specify the "relay" parameter on the subnet level: "relay": { "ip-address": "100.101.101.0" } See: http://kea.isc.org/docs/kea-guide.html#dhcp6-relay-override The classification will be needed for filtering the RAI option values to more specifically select the subnet but relay parameter should narrow down the selection for the relay address. Marcin _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
In reply to this post by Sergey Klusov
Hi,
> On Sep 28, 2017, at 5:49 AM, Sergey Klusov <[hidden email]> wrote: > > On Чт 28.09.2017 14:37, Francis Dupont wrote: >> IMHO the simplest is to write a little hook which resets the giaddr, >> or to understand why the client or relay sets it and fix this. >> >> Regards >> >> Francis Dupont <[hidden email]> >> > Client is a mikrotik router with some specific setup: lan segment which it runs relay for is in VRF instance, but there is a limitation in RouterOS that dhcp-relay destination will be contacted using main routing table. If your relay supports RFC3527, it will reset giaddr to the IP of the relay’s outbound server facing interface instead of the IP of the relay’s inbound, client facing interface. It will also then encode the subnet of the interface that the packet arrived on at the relay into option 82 sub option 5. In Cisco, this is usually enabled using the ‘vpn’ keyword with the 'ip dhcp relay information option’ command. I believe that Kea will then be able to use sub option 5 to select the correct subnet, but in my particular use case, I use RFC3527 only in my lab (I cannot use that feature in production) and I match remote-id in a client-class and include that class in the appropriate subnet declaration, so I don’t honestly know if Kea will use sub option 5 as intended. I could try if you’d like? Standard: 14:58:26.420087 IP (tos 0x0, ttl 253, id 36242, offset 0, flags [none], proto UDP (17), length 343) 10.219.45.114.67 > 10.219.66.10.67: [udp sum ok] BOOTP/DHCP, Request from 00:01:47:dc:fa:5a, length 315, hops 1, xid 0xe53cd04, Flags [none] (0x0000) Gateway-IP 10.63.255.1 Client-Ethernet-Address 00:01:47:dc:fa:5a Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 8: "1448201" Parameter-Request Option 55, length 14: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, Lease-Time, DHCP-Message Server-ID, TFTP, NTP, Time-Zone Option 120, Classless-Static-Route Vendor-Class Option 60, length 20: "ZNID-GE-2628A-NA-0GN" Agent-Information Option 82, length 21: Circuit-ID SubOption 1, length 6: ^@^D^L7^BP Remote-ID SubOption 2, length 11: ^A^Irgw01.lab END Option 255, length 0 14:58:26.429253 IP (tos 0x0, ttl 64, id 12783, offset 0, flags [DF], proto UDP (17), length 368) 10.219.66.10.67 > 10.63.255.1.67: [bad udp cksum 0x5793 -> 0x77ad!] BOOTP/DHCP, Reply, length 340, hops 1, xid 0xe53cd04, Flags [none] (0x0000) Your-IP 10.63.255.115 Gateway-IP 10.63.255.1 Client-Ethernet-Address 00:01:47:dc:fa:5a file "26xx_current/S0300608"[|bootp] RFC3527: 15:10:33.158538 IP (tos 0x0, ttl 253, id 36799, offset 0, flags [none], proto UDP (17), length 380) 10.219.45.114.67 > 10.219.66.10.67: [udp sum ok] BOOTP/DHCP, Request from 00:01:47:e3:2f:60, length 352, hops 1, xid 0x507b2ecb, Flags [none] (0x0000) Gateway-IP 10.219.45.114 Client-Ethernet-Address 00:01:47:e3:2f:60 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 8: "1488880" Parameter-Request Option 55, length 14: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, Lease-Time, DHCP-Message Server-ID, TFTP, NTP, Time-Zone Option 120, Classless-Static-Route Vendor-Class Option 60, length 20: "ZNID-GE-2628A-00-0GN" Agent-Information Option 82, length 58: Circuit-ID SubOption 1, length 6: ^@^D^L7^B^A Remote-ID SubOption 2, length 11: ^A^Irgw01.lab Unknown SubOption 151, length 23: 0x0000: 0072 6573 6964 656e 7469 616c 2d6d 616e 0x0010: 6167 656d 656e 74 Unknown SubOption 5, length 4: 0x0000: 0a3f ff00 Unknown SubOption 152, length 4: 0x0000: 0a3f ff01 END Option 255, length 0 15:10:33.169563 IP (tos 0x0, ttl 64, id 61753, offset 0, flags [DF], proto UDP (17), length 405) 10.219.66.10.67 > 10.219.45.114.67: [bad udp cksum 0x86c4 -> 0x8fae!] BOOTP/DHCP, Reply, length 377, hops 1, xid 0x507b2ecb, Flags [none] (0x0000) Your-IP 10.63.255.16 Gateway-IP 10.219.45.114 Client-Ethernet-Address 00:01:47:e3:2f:60 file "26xx_current/S0300608"[|bootp] > Because of that, relay messages are sent out-of-band, using different interface. > > Right now i'm working on supplying additional option 82 information to kea, by wich it should select appropriate subnet. > > 14:30:40.033857 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 360) > x.x.x.156.67 > x.x.x.90.67: [udp sum ok] BOOTP/DHCP, Request from f4:8b:32:a3:79:3f, length 332, hops 1, xid 0xa111bece, secs 17, Flags [none] (0x0000) > Gateway-IP x.x.x.156 > Client-Ethernet-Address f4:8b:32:a3:79:3f > Vendor-rfc1048 Extensions > Magic Cookie 0x63825363 > DHCP-Message Option 53, length 1: Discover > Client-ID Option 61, length 7: ether f4:8b:32:a3:79:3f > MSZ Option 57, length 2: 1500 > Vendor-Class Option 60, length 18: "android-dhcp-6.0.1" > Hostname Option 12, length 17: "MINOTELTE-MiPhone" > Parameter-Request Option 55, length 9: > Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name > MTU, BR, Lease-Time, RN > RB > Agent-Information Option 82, length 23: > Circuit-ID SubOption 1, length 6: M-~^K.M-AM-tz > Remote-ID SubOption 2, length 13: 100.101.101.0 > > Can someone tell me how to make kea select subnet 100.101.101.0/24 by Remote-ID "100.101.101.0" suboption and giaddr? > > Should i define some class and apply it to subnet? > > _______________________________________________ > Kea-users mailing list > [hidden email] > https://lists.isc.org/mailman/listinfo/kea-users _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
On Чт 28.09.2017 16:54, Jason Lixfeld wrote:
> If your relay supports RFC3527, it will reset giaddr to the IP of the > relay’s outbound server facing interface instead of the IP of the > relay’s inbound, client facing interface. It will also then encode the > subnet of the interface that the packet arrived on at the relay into > option 82 sub option 5. I've already configured agent to set it's giarrd to external address and also specified that address in subnet's "relay" setting. Still i need to use classes, because there will be tens of networks on this router, all of them dhcp-relayed to same kea server. Here is how i configure agent: /ip dhcp-relay add add-relay-info=yes\ dhcp-server=x.x.x.90\ disabled=no\ interface=eoip-101\ local-address=x.x.x.156\ name=relay1\ relay-info-remote-id=100.101.101.0 that "relay-info-remote-id" could only be specified as ASCII string value, and it's seen by kea as relay4[2] option. But kea now cannot compare this option with string '100.101.101.0', only with it's hex value. Wich is working, but just not comfortable configuring. _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
> On Sep 28, 2017, at 8:16 AM, Sergey Klusov <[hidden email]> wrote: > > On Чт 28.09.2017 16:54, Jason Lixfeld wrote: >> If your relay supports RFC3527, it will reset giaddr to the IP of the relay’s outbound server facing interface instead of the IP of the relay’s inbound, client facing interface. It will also then encode the subnet of the interface that the packet arrived on at the relay into option 82 sub option 5. > > I've already configured agent to set it's giarrd to external address and also specified that address in subnet's "relay" setting. > Still i need to use classes, because there will be tens of networks on this router, all of them dhcp-relayed to same kea server. > > Here is how i configure agent: > > /ip dhcp-relay > add add-relay-info=yes\ > dhcp-server=x.x.x.90\ > disabled=no\ > interface=eoip-101\ > local-address=x.x.x.156\ > name=relay1\ > relay-info-remote-id=100.101.101.0 > > that "relay-info-remote-id" could only be specified as ASCII string value, and it's seen by kea as relay4[2] option. But kea now cannot compare this option with string '100.101.101.0', only with it's hex value. Wich is working, but just not comfortable configuring. If RFC3527 is supported on your Mikrotik, it could make this all much easier. Do you know if it is? If so, it should just work without a need to do classes or anything. Just a subnet declaration. SubOption 5 below decodes to 172 31 255 0, so it seems that Kea supports it properly. { #"client-class" : "rgw01.lab", "subnet": "172.31.255.0/28", "valid-lifetime": 300, "option-data": [ { "name": "classless-static-routes", "data": "18AC1800AC1FFF01" } ], "pools": [ { "pool": "172.31.255.2 - 172.31.255.14" } ] } 11:43:31.016608 IP (tos 0x0, ttl 253, id 21231, offset 0, flags [none], proto UDP (17), length 361) 10.219.45.114.67 > 10.219.66.10.67: [udp sum ok] BOOTP/DHCP, Request from 00:01:47:dc:fa:5b, length 333, hops 1, xid 0x4ee7ebbc, Flags [none] (0x0000) Gateway-IP 10.219.45.114 Client-Ethernet-Address 00:01:47:dc:fa:5b Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 00:01:47:dc:fa:5b Parameter-Request Option 55, length 14: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, Lease-Time, DHCP-Message Server-ID, TFTP, NTP, Time-Zone Option 120, Classless-Static-Route Vendor-Class Option 60, length 10: "VOIP_2628A" Agent-Information Option 82, length 50: Circuit-ID SubOption 1, length 6: ^@^D^KM-=^BP Remote-ID SubOption 2, length 11: ^A^Irgw01.lab Unknown SubOption 151, length 15: 0x0000: 0076 6f69 702d 756e 7472 7573 7465 64 Unknown SubOption 5, length 4: 0x0000: ac1f ff00 Unknown SubOption 152, length 4: 0x0000: ac1f ff01 END Option 255, length 0 11:43:31.031137 IP (tos 0x0, ttl 64, id 30423, offset 0, flags [DF], proto UDP (17), length 373) 10.219.66.10.67 > 10.219.45.114.67: [bad udp cksum 0x86a4 -> 0x44bd!] BOOTP/DHCP, Reply, length 345, hops 1, xid 0x4ee7ebbc, Flags [none] (0x0000) Your-IP 172.31.255.2 Gateway-IP 10.219.45.114 Client-Ethernet-Address 00:01:47:dc:fa:5b Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.255.240 Lease-Time Option 51, length 4: 300 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 10.219.66.10 RN Option 58, length 4: 900 RB Option 59, length 4: 1800 Client-ID Option 61, length 7: ether 00:01:47:dc:fa:5b Classless-Static-Route Option 121, length 8: (172.24.0.0/24:172.31.255.1) Agent-Information Option 82, length 50: Circuit-ID SubOption 1, length 6: ^@^D^KM-=^BP Remote-ID SubOption 2, length 11: ^A^Irgw01.lab Unknown SubOption 5, length 4: 0x0000: ac1f ff00 Unknown SubOption 151, length 15: 0x0000: 0076 6f69 702d 756e 7472 7573 7465 64 Unknown SubOption 152, length 4: 0x0000: ac1f ff01 END Option 255, length 0 11:43:31.041859 IP (tos 0x0, ttl 253, id 21235, offset 0, flags [none], proto UDP (17), length 373) 10.219.45.114.67 > 10.219.66.10.67: [udp sum ok] BOOTP/DHCP, Request from 00:01:47:dc:fa:5b, length 345, hops 1, xid 0x4ee7ebbc, Flags [none] (0x0000) Gateway-IP 10.219.45.114 Client-Ethernet-Address 00:01:47:dc:fa:5b Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Client-ID Option 61, length 7: ether 00:01:47:dc:fa:5b Requested-IP Option 50, length 4: 172.31.255.2 Server-ID Option 54, length 4: 10.219.66.11 Parameter-Request Option 55, length 14: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, Lease-Time, DHCP-Message Server-ID, TFTP, NTP, Time-Zone Option 120, Classless-Static-Route Vendor-Class Option 60, length 10: "VOIP_2628A" Agent-Information Option 82, length 50: Circuit-ID SubOption 1, length 6: ^@^D^KM-=^BP Remote-ID SubOption 2, length 11: ^A^Irgw01.lab Unknown SubOption 151, length 15: 0x0000: 0076 6f69 702d 756e 7472 7573 7465 64 Unknown SubOption 5, length 4: 0x0000: ac1f ff00 Unknown SubOption 152, length 4: 0x0000: ac1f ff01 END Option 255, length 0 11:46:02.272355 IP (tos 0x0, ttl 64, id 41786, offset 0, flags [DF], proto UDP (17), length 363) 10.219.66.10.67 > 10.219.45.114.67: [bad udp cksum 0x869a -> 0xeb84!] BOOTP/DHCP, Reply, length 335, hops 1, xid 0x4ee7ebbc, Flags [none] (0x0000) Client-IP 172.31.255.2 Your-IP 172.31.255.2 Gateway-IP 10.219.45.114 Client-Ethernet-Address 00:01:47:dc:fa:5b Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.255.240 Lease-Time Option 51, length 4: 300 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 10.219.66.10 RN Option 58, length 4: 900 RB Option 59, length 4: 1800 Client-ID Option 61, length 7: ether 00:01:47:dc:fa:5b Agent-Information Option 82, length 50: Circuit-ID SubOption 1, length 6: ^@^D^KM-=^BP Remote-ID SubOption 2, length 11: ^A^Irgw01.lab Unknown SubOption 5, length 4: 0x0000: ac1f ff00 Unknown SubOption 151, length 15: 0x0000: 0076 6f69 702d 756e 7472 7573 7465 64 Unknown SubOption 152, length 4: 0x0000: ac1f ff01 END Option 255, length 0 _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
On Чт 28.09.2017 20:56, Jason Lixfeld wrote:
> > If RFC3527 is supported on your Mikrotik, it could make this all much easier. Do you know if it is? If so, it should just work without a need to do classes or anything. Just a subnet declaration. > Just read RFC3527 - very usefull, but Mikrotik does not support it. I wonder why they decided to send replies to giaddr in original DHCP standart. From my point of view it would be wise to reply to packet sender. Those old standarts.... _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
Free forum by Nabble | Edit this page |