[Kea-users] Vendor-Identifying option 125 vivso-suboptions
Evan Carson
ecarson at 128technology.com
Thu Nov 7 18:35:00 UTC 2019
Hi Rob,
Thank you for the info. I think this would work although our customer we
are integrating a solution for claims that his requires option 125
specifically. I'm not sure that is necessarily true but that is what he is
claiming based on his previous server setup. If I can't figure out how to
get the vendor identifying options working I will get them to test out
option 43 as you configure it above.
I'm curious if there is a way to get option 125 working to encapsulate the
right vendor ID with the options included. From the docs I believe Kea
allows it and I think I have it configured correctly above but it's only
sending out an empty option.
Thanks again,
Evan
On Thu, Nov 7, 2019 at 10:23 AM Sutherland, Rob <
Robert.B.Sutherland at windstream.com> wrote:
> Here’s what worked for my Mitel phones (note that I used option 43):
>
>
>
> "client-classes": [
>
> {
>
> "name": "mitel",
>
> "test": "substring(option[60].hex,0,17) == 'ipphone.mitel.com'",
>
> "option-def": [
>
> {
>
> "name": "vendor-encapsulated-options",
>
> "code": 43,
>
> "type": "string"
>
> }
>
> ],
>
> "option-data": [
>
> {
>
> "name": "vendor-encapsulated-options",
>
> "data": "id:ipphone.mitel.com
> ;sw_tftp=10.151.75.34;call_srv=10.151.75.32"
>
> }
>
> ]
>
> },
>
>
>
> *From:* Kea-users <kea-users-bounces at lists.isc.org> * On Behalf Of *Evan
> Carson
> *Sent:* Wednesday, November 6, 2019 4:00 PM
> *To:* kea-users at lists.isc.org
> *Subject:* [Kea-users] Vendor-Identifying option 125 vivso-suboptions
>
>
>
> Hello,
>
>
>
> We are running Kea 1.4.0 and are having trouble getting the server to hand
> out option 125 to a Mitel phone. The Kea server is replying to the client
> with this data in the DHCP offer with an empty option 125 containing only
> the Mitel enterprise option but no data.
>
>
>
> We have this option definition specified in the Dhcp4 config:
>
> "option-def": [
> {
> "array": false,
> "code": 130,
> "encapsulate": "",
> "name": "mitel-option",
> "record-types": "",
> "space": "vendor-1027",
> "type": "string"
> }
> ],
>
>
>
> We then placed this option in the subnet["pools"]["option-data"] for our
> phone subnet
>
> {
> "name": "vivso-suboptions",
> "data": "1027"
> },
> {
> "name": "mitel-option",
> "space": "vendor-1027",
> "data": "id:ipphone.mitel.com
> <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fipphone.mitel.com&data=02%7C01%7CRobert.B.Sutherland%40windstream.com%7Cfe63ef71459047eeb95b08d762fc465b%7C2567b4c1b0ed40f5aee358d7c5f3e2b2%7C1%7C1%7C637086707970887653&sdata=ybRRfpPu13cnOyzXLUV2ojFqrTIFjusuUu%2BijhCjs1s%3D&reserved=0>
> ;sw_tftp=10.78.182.2;call_srv=10.78.182.2;vlan=71;l2p=6;dscp=46;"
> }
>
>
>
> Here is the DHCP Offer pcap coming back from server:
>
>
>
> Frame 15952: 332 bytes on wire (2656 bits), 332 bytes captured (2656 bits)
> Ethernet II, Src: RealtekU_e9:ea:63 (52:54:00:e9:ea:63), Dst:
> SmcStand_9c:c6:36 (08:00:0f:9c:c6:36)
> Internet Protocol Version 4, Src: 192.168.1.1, Dst: 255.255.255.255
> User Datagram Protocol, Src Port: 67, Dst Port: 68
> Bootstrap Protocol (Offer)
> Message type: Boot Reply (2)
> Hardware type: Ethernet (0x01)
> Hardware address length: 6
> Hops: 0
> Transaction ID: 0x99cc086f
> Seconds elapsed: 0
> Bootp flags: 0x8000, Broadcast flag (Broadcast)
> Client IP address: 0.0.0.0
> Your (client) IP address: 192.168.1.102
> Next server IP address: 0.0.0.0
> Relay agent IP address: 0.0.0.0
> Client MAC address: SmcStand_9c:c6:36 (08:00:0f:9c:c6:36)
> Client hardware address padding: 00000000000000000000
> Server host name: KVM_128T_Remote
> Boot file name not given
> Magic cookie: DHCP
> Option: (1) Subnet Mask
> Option: (3) Router
> Option: (6) Domain Name Server
> Option: (51) IP Address Lease Time
> Option: (53) DHCP Message Type (Offer)
> Option: (54) DHCP Server Identifier
> Option: (61) Client identifier
> Option: (125) V-I Vendor-specific Information
> Length: 5
> Enterprise: Mitel, Corp. (1027)
> Length: 0
> Option: (255) End
>
> It looks like the configuration for the enterprise ID is working correctly
> however the custom "mitel-option" string doesn't seem to be contributing.
> Is there anything wrong with the way we have this configured?
>
>
>
> We aren't using any client-class configuration to restrict this option to
> only the clients requesting a given Vendor-Identifying Vendor Class option.
> Is it a requirement that the client-classification be used to specify the
> vendor class option?
>
>
>
> Thank you for your help,
>
>
>
> Evan Carson
>
>
>
> Sensitivity: Internal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20191107/fd9a34b6/attachment.htm>
More information about the Kea-users
mailing list